rfc3157.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/4 页

Arsenault & Farrell          Informational                      [Page 5]

RFC 3157                 SACRED - Requirements               August 2001


   For example, consider the case where Mimi sends a message from her
   wireless phone containing the credentials in question, and retrieves
   it using her two-way pager.  In getting from one place to another,
   the bits of the message cross the wireless phone network to a base
   station.  These bits are likely transferred over the wired phone
   network to a message server run by the wireless phone operator, and
   are transferred from there over the Internet to a message server run
   by the paging operator.  From the paging operator they are
   transferred to a base station and then finally to Mimi's pager.
   Certainly, there are devices other than the original wireless phone
   and ultimate pager that are involved in the credential transfer, in
   the sense that they transmit bits from one place to another.
   However, to all devices except the pager and the wireless phone, what
   is being transferred is an un-interpreted and unprocessed set of
   bits.  No security-related decisions are made, and no actions are
   taken based on the fact that this message contains credentials, at
   any of the intermediate nodes.  They exist simply to forward bits.
   Thus, we consider this to be a "direct" transfer of credentials.

   Solutions involving the direct transfer of credentials from one
   device to another are potentially somewhat more complex than the
   credential-server approach, owing to the large number of different
   devices and formats that may have to be supported.  Complexity is
   also added due to the fact that each device may in turn have to
   exhibit the behavior of both a client and a server.

   We believe that both classes of solutions are useful in certain
   environments, and thus that the SACRED framework will have to define
   solutions for both.  The extent to which elements of the above
   solutions overlap remains to be determined.

   This all leads to our first set of requirements:

   F1.   The framework MUST support both "credential server" and
         "direct" solutions.
   F2.   The "credential server" and "direct" solutions SHOULD use the
         same technology as far as possible.

2.2 User authentication

   There is a wide range of deployment options for credential mobility
   solutions.  In many of these cases, it is useful to be able to re-use
   an existing user authentication scheme, for example where passwords
   have previously been established, it may be more secure to re-use
   these than try to manage a whole new set of passwords.  Different
   devices may also limit the types of user authentication scheme that
   are possible, e.g., not all mobile devices are practically capable of
   carrying out asymmetric cryptography.



Arsenault & Farrell          Informational                      [Page 6]

RFC 3157                 SACRED - Requirements               August 2001


   F3.   The framework MUST allow for protocols which support different
         user authentication schemes

2.3 Credential Formats

         Today there is no single standard format for credentials and
         this is not likely to change in the near future.  There are a
         number of fairly widely deployed formats, e.g., [PGP],
         [PKCS#12] that have to be supported.  This means that the
         framework has to allow for protocols supporting any credential
         format.

   F4.   The details of the actual credential type or format MUST be
         opaque to the protocol, though not to processing within the
         protocol's peers.  The protocol MUST NOT depend on the internal
         structure of any credential type or format.

2.4 Transport Issues

   Different devices allow for different transport layer possibilities,
   e.g., current WAP 1.x devices do not support TCP.  For this reason
   the framework has to be transport "agnostic".

   F5.   The framework MUST allow use of different transports.

3. Protocol Requirements

   In this section, we identify the requirements for secure credential-
   transfer solutions.  We will begin by listing a set of relevant
   vulnerabilities and the requirements that must be met by all
   solutions.  Then we identify additional requirements that must be met
   by solutions involving a credential server, followed by additional
   requirements that must be met by solutions involving direct transfer
   of credentials.

3.1 Vulnerabilities

   This section lists the vulnerabilities against which a SACRED
   protocol SHOULD offer protection.  Any protocol claiming to meet the
   requirements listed in this document MUST explicitly indicate how (or
   whether) it offers protection for each of these vulnerabilities.

   V1.      A passive attacker can watch all packets on the network and
            later carry out a dictionary attack.
   V2.      An attacker can attempt to masquerade as a credential server
            in an attempt to get a client to reveal information on line
            that allows for a later dictionary attack.




Arsenault & Farrell          Informational                      [Page 7]

RFC 3157                 SACRED - Requirements               August 2001


   V3.      An attacker can attempt to get a client to decrypt a chosen
            "ciphertext" and get the client to make use of the resulting
            plaintext - the attacker may then be able to carry out a
            dictionary attack (e.g., if the plaintext resulting from
            "decryption" of a random string is used as a DSA private
            key).
   V4.      An attacker could overwrite a repository entry so that when
            a user subsequently uses what they think is a good
            credential, they expose information about their password
            (and hence the "real" credential).
   V5.      An attacker can copy a credential server's repository and
            carry out a dictionary attack.
   V6.      An attacker can attempt to masquerade as a client in an
            attempt to get a server to reveal information that allows
            for a later dictionary attack.
   V7.      An attacker can persuade a server that a successful login
            has occurred, even if it hasn't.
   V8.      (Upload) An attacker can overwrite someone else's
            credentials on the server.
   V9.      (When using password-based authentication) An attacker can
            force a password change to a known (or "weak") password.
   V10.     An attacker can attempt a man-in-the-middle attack for lots
   V11.     User enters password instead of name.
   V12.     An attacker could attempt various denial-of-service attacks.

3.2 General Protocol Requirements

   Looking again at the examples described in Section 1.1, we can
   readily see that there are a number of requirements that must apply
   to the transfer of credentials if the ultimate goal of supporting the
   Internet security protocols (e.g., TLS, IPSec, S/MIME) is to be met.
   For example, the credentials must remain confidential at all times;
   it is unacceptable for nodes other than the end-user's device(s) to
   see the credentials in any readable, cleartext form.

   These, then, are the requirements that apply to all secure
   credential-transfer solutions:

   G1.      Credential transfer both to and from a device MUST be
            supported.
   G2.      Credentials MUST NOT be forced by the protocol to be present
            in cleartext at any device other than the end user's.
   G3.      The protocol SHOULD ensure that all transferred credentials
            be authenticated in some way (e.g., digitally signed or
            MAC-ed).
   G4.      The protocol MUST support a range of cryptographic
            algorithms, including symmetric and asymmetric algorithms,
            hash algorithms, and MAC algorithms.



Arsenault & Farrell          Informational                      [Page 8]

RFC 3157                 SACRED - Requirements               August 2001


   G5.      The protocol MUST allow the use of various credential types
            and formats (e.g., X.509, PGP, PKCS12, ...).
   G6.      One mandatory to support credential format MUST be defined.
   G7.      One mandatory to support user authentication scheme MUST be
            defined.
   G8.      The protocol MAY allow credentials to be labeled with a text
            handle, (outside the credential), to allow the end user to
            select amongst a set of credentials or to name a particular
            credential.
   G9.      Full I18N support is REQUIRED (via UTF8 support) [RFC2277].
   G10.     It is desirable that the protocol be able to support
            privacy, that is, anonymity for the client.
   G11.     Transferred credentials MAY incorporate timing information,
            for example a "time to live" value determining the maximum
            time for which the credential is to be usable following
            transfer/download.

3.3 Requirements for Credential Server-based solutions

   The following requirements assume that there is a credential server
   from which credentials are downloaded to the end user device, and to
   which credentials are uploaded from an end user device.

   S1.      Credential downloads (to an end user) and upload (to the
            credential server) MUST be supported.
   S2.      Credentials MUST only be downloadable following user
            authentication or else only downloaded in a format that
            requires completion of user authentication for deciphering.
   S3.      It MUST be possible to ensure the authenticity of a
            credential during upload.
   S4.      Different end user devices MAY be used to
            download/upload/manage the same set of credentials.
   S5.      Credential servers SHOULD be authenticated to the user for
            all operations except download.  Note: This requirement can
            be ignored if the credential format itself is strongly
            protected, as there is no risk (other than user confusion)
            from an unauthenticated credential server.
   S6.      It SHOULD be possible to authenticate the credential server
            to the user as part of a download operation.
   S7.      The user SHOULD only have to enter a single secret value in
            order to download and use a credential.
   S8.      Sharing of secrets across multiple servers MAY be possible,
            so that penetration of some servers does not expose the
            private parts of a credential ("m-from-n" operation).
   S9.      The protocol MAY support "away-from-home" operation, where
            the user enters both a name and a domain (e.g.
            [e-mail]) and the domain can be used in
            order to locate the user's credential server.



Arsenault & Farrell          Informational                      [Page 9]

RFC 3157                 SACRED - Requirements               August 2001


   S10.     The protocol MUST provide operations allowing users to
            manage their credentials stored on the credential server,
            e.g., to retrieve a list of their credentials stored on a
            server; add credentials to the server; delete credentials
            from the server.
   S11.     Client-initiated authentication information (e.g., password)
            change MUST be supported.
   S12.     The user SHOULD be able to retrieve a list of
            accesses/changes to their credentials.
   S13.     The protocol MUST support user self-enrollment.  One
            scenario calling for this is where a previously unknown user
            uploads his credential without requiring manual operator
            intervention.
   S14.     The protocol MUST NOT prevent bulk initializing of a
            credential server's repository.
   S15.     The protocol SHOULD require minimal client configuration.

3.4 Requirements for Direct-Transfer Solutions

   The full set of requirements for this case has not been elucidated,
   and this list is therefore provisional.  An additional requirements
   document (or a modification of this one) will be required prior to
   progression of a direct-transfer protocol.

   The following requirements apply to solutions supporting the "direct"
   transfer of credentials from one device to another.  (See Section 2
   for the note on the meaning of "direct" in this case.)

   D1.   It SHOULD be possible for the receiving device to authenticate
         that the credential package indeed came from the purported
         sending device.
   D2.   In order for a sender to know that a credential has been
         received by a recipient, it SHOULD be possible for the
         receiving device to send an acknowledgment of credential
         receipt back to the sending device, and for the sending device
         to authenticate this acknowledgment.

4. Security Considerations

4.1 Hardware vs. Software

   Mobile credentials will never be as secure as a "pure" hardware-based
   solution, because of potential attacks through the operating system
   of the end-user device.  However, an acceptable level of security may
   be accomplished through some simple means.  In fact the level of
   security may be improved (compared to password encrypted files)
   through the use of SACRED protocols.




Arsenault & Farrell          Informational                     [Page 10]