home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-petke-serv-deity-protocol-00.txt < prev    next >
Text File  |  1996-11-16  |  27KB  |  688 lines
  1.  
  2.  
  3. INTERNET-DRAFT                                                   G Brown
  4. draft-petke-serv-deity-protocol-00.txt                        CompuServe
  5. Expires: 15-May-97                                      15 November 1996
  6.  
  7.  
  8.                     Remote Passphrase Authentication
  9.                   Part Four:  Service-to-Deity Protocol
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.    This document is an Internet-Draft.  Internet-Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its
  16.    areas, and its working groups.  Note that other groups may also
  17.    distribute working documents as Internet-Drafts.
  18.  
  19.    Internet-Drafts are draft documents valid for a maximum of six
  20.    months and may be updated, replaced, or obsoleted by other
  21.    documents at any time.  It is inappropriate to use Internet-
  22.    Drafts as reference material or to cite them other than as
  23.    "work in progress."
  24.  
  25.    To learn the current status of any Internet-Draft, please check
  26.    the "1id-abstracts.txt" listing contained in the Internet-
  27.    Drafts Shadow Directories on ftp.is.co.za (Africa),
  28.    nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  29.    ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  30.    
  31.  
  32. Abstract 
  33.    
  34.    Remote Passphrase Authentication provides a way to authenticate a 
  35.    user to a service by using a pass phrase over an insecure network, 
  36.    without revealing the pass phrase to eavesdroppers. In addition, the
  37.    service need not know and does not learn the user's pass phrase, 
  38.    making this scheme useful in distributed environments where it would 
  39.    be difficult or inappropriate to trust a service with a pass phrase 
  40.    database or to allow the server to learn enough to masquerade as the 
  41.    user in a future authentication attempt.
  42.  
  43.    This draft is part four of a four part series and explains the
  44.    protocol between the service and the deity.  Part one of this series
  45.    (draft-petke-ext-intro-00.txt) provides an extended introduction to
  46.    the problems of authentication over insecure networks.  Part two
  47.    (draft-petke-mech-00.txt) explains the RPA mechanism.  Part three
  48.    (draft-petke-http-auth-scheme-00.txt) explains how to incorporate
  49.    the mechanism into HTTP.
  50.  
  51.    This scheme was inspired by Dave Raggett's Mediated Digest
  52.    Authentication paper.
  53.  
  54.    
  55.  
  56.  
  57.  
  58. G Brown                                                         [Page 1]
  59.  
  60. INTERNET-DRAFT             RPA - Part Four              15 November 1996
  61.  
  62.   
  63. Table of Contents 
  64.    
  65.    1. INTRODUCTION 
  66.    
  67.    2. OBJECT FORMATS
  68.  
  69.    3. THE BLOB
  70.  
  71.    4. MESSAGE OBJECT TYPES
  72.    4.1 AUTHENTICATION REQUEST
  73.    4.2 AUTHENTICATION RESPONSE, AFFIRMATIVE
  74.    4.3 AUTHENTICATION RESPONSE, NO SERVICE
  75.    4.4 AUTHENTICATION RESPONSE, NEGATIVE
  76.    4.5 AUTHENTICATION RESPONSE, INVALID SERVICE
  77.    4.6 AUTHENTICATION RESPONSE, PROBLEM
  78.  
  79.    5. OBJECT TYPES
  80.  
  81.    6. THE BLOB
  82.  
  83.    7. SECURITY CONSIDERATIONS
  84.  
  85.    8. AUTHOR'S ADDRESS
  86.  
  87.  
  88. 1. Introduction 
  89.    
  90.    The service sends a request to the authentication deity and receives 
  91.    a reply. The requests and replies may be packaged in UDP datagrams, 
  92.    or as byte streams over a TCP connection. The tradeoff is primarily 
  93.    that opening a TCP connection requires multiple round trip delays, 
  94.    where UDP doesn't; but TCP avoids the "I wonder whether it's actually
  95.    running" issue. 
  96.    
  97.    How to find the deity is a service configuration issue. The service 
  98.    must know the IP addresses, TCP or UDP port numbers, etc., for the 
  99.    deities for a particular realm; it must also know its name and pass 
  100.    phrase in that realm. 
  101.    
  102.  
  103. 2. Object formats 
  104.    
  105.    Every message is an object composed of other objects. Every object 
  106.    consists of a type-length-value encoded structure: 
  107.    
  108.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  109.    |     Type      |   Length MSB  |   Length LSB  | Value octet 1 |
  110.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  111.    | Value octet 2 | Value octet 3 | Value octet 4 |      ...      |
  112.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  113.  
  114.  
  115. G Brown                                                         [Page 2]
  116.  
  117. INTERNET-DRAFT             RPA - Part Four              15 November 1996
  118.  
  119.    
  120.    In this picture, each box represents one octet. Octets are 
  121.    transmitted in order from left to right, top to bottom. 
  122.    
  123.    "Type" is a single octet that identifies the type of the object. 
  124.    
  125.    "Length" indicates the number of octets following the length field, 
  126.    as a 16-bit, big-endian value. The appropriate number of value 
  127.    octets--possibly none--follow the length field. Their meaning is 
  128.    determined by the type of the object; in some cases, the value octets
  129.    contain a sequence of other objects. 
  130.    
  131.    Here is an example of an object that contains 4 value octets: 
  132.    
  133.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  134.    |     Type      |0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0| Value octet 1 |
  135.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  136.    | Value octet 2 | Value octet 3 | Value octet 4 |
  137.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  138.    
  139.    And here is an example of an object that contains 1,000 value octets:
  140.    
  141.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  142.    |     Type      |0 0 0 0 0 0 1 1|1 1 1 0 1 0 0 0| Value octet 1 |
  143.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  144.    | Value octet 2 | Value octet 3 | Value octet 4 | Value octet 5 |
  145.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  146.    |                              ...                              |
  147.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  148.    |Value octet 996|Value octet 997|Value octet 998|Value octet 999|
  149.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  150.    |Value octet1000|
  151.    +-+-+-+-+-+-+-+-+
  152.    
  153.    No padding or alignment is used; if an object contains sub-objects, 
  154.    they follow one another with no padding. For example, an object whose 
  155.    value consists of three sub-objects might look like this: 
  156.    
  157.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  158.    |  Object type  |   00000000    |   00001111    |Sub-obj 1 type |
  159.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  160.    |   00000000    |   00000101    | Value octet 1 | Value octet 2 |
  161.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  162.    | Value octet 3 | Value octet 4 | Value octet 5 |Sub-obj 2 type |
  163.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  164.    |   00000000    |   00000000    |Sub-obj 3 type |   00000000    |
  165.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  166.    |   00000001    | Value octet 1 |
  167.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  168.  
  169.  
  170.  
  171.  
  172. G Brown                                                         [Page 3]
  173.  
  174. INTERNET-DRAFT             RPA - Part Four              15 November 1996
  175.  
  176.    
  177.    In this example, we have a single object whose value contains 15 
  178.    octets. In this example, the value is a sequence of three objects, 
  179.    the first of which contains five octets, the second of which is zero 
  180.    length, and third of which contains one octet. The meaning of each 
  181.    object depends on its type; we'll describe all object types in detail
  182.    after describing the message objects. 
  183.    
  184.    We'll sometimes use the term "sub-object" to refer to an object when 
  185.    it is a part of another object, but this is merely a matter of 
  186.    terminology. There is no difference in encoding nor in the meaning of
  187.    the type field, regardless of whether the object is contained in some 
  188.    other object or not. 
  189.    
  190.  
  191. 3. The blob 
  192.    
  193.    All messages may contain a "blob" that conveys information defined by
  194.    a particular deity. The blob is used in three contexts. 
  195.    
  196.    * In a request, a service may use the blob to tell the deity the 
  197.      nature of the action for which authentication is being performed, 
  198.      if there's some reason to do so. In addition, the service might ask
  199.      the deity for particular information about the username being 
  200.      authenticated, although, in the general case, the deity will 
  201.      already know what additional information to return to a particular 
  202.      service. 
  203.      
  204.    * In an affirmative response, the deity may return additional 
  205.      information about the username. 
  206.      
  207.    * In other responses, the blob might indicate something about the 
  208.      nature of the problem. 
  209.      
  210.    In general, different deities and services will have different 
  211.    information that's appropriate for inclusion in the blob, so it is 
  212.    difficult to conceive of a truly "standard" set of information. Thus,
  213.    the definition of the blob's contents is left to each deity, but we 
  214.    define one format for inclusion of attribute/value pairs. 
  215.    
  216.    Should information in the blob be encrypted? That's a deity 
  217.    configuration issue. Beware, though, of naively encrypting the blob 
  218.    by XOR'ing it with the session key. That would reveal parts of the 
  219.    key because, in general, portions of the plaintext are known. 
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.    
  229. G Brown                                                         [Page 4]
  230.  
  231. INTERNET-DRAFT             RPA - Part Four              15 November 1996
  232.  
  233.  
  234. 4. Message object types 
  235.    
  236.    There are six message object types, one for a request and five kinds
  237.    of replies. 
  238.    
  239.    * Authentication request 
  240.    * Authentication response, affirmative 
  241.    * Authentication response, no service 
  242.    * Authentication response, negative 
  243.    * Authentication response, invalid service 
  244.    * Authentication response, problem 
  245.      
  246.    The various response flavors indicate various conditions of the 
  247.    account as described below. 
  248.    
  249.    Remember, a message is simply an object that contains other objects. 
  250.    The message itself is encoded as a type, length, and value, as 
  251.    described above, where the value consists of the concatenation of the
  252.    component objects of that message; each component object consists of 
  253.    its own type, length, and value. Unless stated to the contrary, all 
  254.    messages must contain exactly the objects indicated in the order 
  255.    shown. Optional components, such as the blob, may be omitted. 
  256.    
  257.         [When appropriate, it is possible to add extensions, or 
  258.         make a sub-object optional, yet parse the containing object 
  259.         successfully. But in a security protocol, it is best to 
  260.         stick to well-defined formats, rather than adopting a 
  261.         "construct them any way you wish" attitude.] 
  262.    
  263.    Contents of the component objects are explained in more detail 
  264.    following the descriptions of the message objects. 
  265.  
  266.    
  267. 4.1 Authentication request
  268.    
  269.    An authentication request contains the following sub-objects. 
  270.    
  271.        Request identifier
  272.        Nr (Realm name)
  273.        Ns (Service name)
  274.        Nu (User name)
  275.        Cu (Challenge from user)
  276.        Cs (Challenge from service)
  277.        Ts (Timestamp from service)
  278.        Ru (Response from user)
  279.        Blob (optional)
  280.        Rs (Response from service)
  281.    
  282.    The value contained in most of the sub-objects matches the value 
  283.    described in part two of this specification
  284.    (draft-petke-mech-00.txt).
  285.  
  286. G Brown                                                         [Page 5]
  287.  
  288. INTERNET-DRAFT             RPA - Part Four              15 November 1996
  289.  
  290.    
  291.    The request identifier contains arbitrary data that is not 
  292.    interpreted by the deity; it is simply echoed in a response to 
  293.    provide a way for the requesting service to match requests and 
  294.    responses. 
  295.    
  296.    The blob contains additional information about the request, and is 
  297.    described below. Usually, it will be omitted or null, i.e., 
  298.    zero-length. 
  299.    
  300.    Rs is calculated as MD5(Ps + Z + M + Ps), where M is the request 
  301.    shown above, octet by octet, from the type octet for the message 
  302.    object itself through the last length octet of the length field of 
  303.    the Rs object. Thus, it serves to protect the entire request, 
  304.    including its structure, length, etc., and is a different calculation
  305.    from that shown in the authentication document. 
  306.  
  307.    
  308. 4.2 Authentication response, affirmative 
  309.    
  310.    An affirmative response indicates that the username is recognized, 
  311.    and is indeed the user you're talking to. 
  312.    
  313.        Request identifier
  314.        Canonical Nu (User name, case corrected)
  315.        Kuss (Key obscured for service)
  316.        Kusu (Key obscured for user)
  317.        Au (Authentication value for user)
  318.        Blob (optional)
  319.        As (Authentication value for service)
  320.    
  321.    The response contains the canonical username in the desired case; 
  322.    this is not the same object type as Nu in the request. In an 
  323.    environment that is not case sensitive, this is the preferred form of
  324.    the name, which might differ from the name in the request. 
  325.    
  326.    The blob may contain additional information about the username; see 
  327.    below. 
  328.    
  329.    As is calculated as 
  330.    
  331.        MD5(Ps + Z + Ns + Nu + Nr + Kuss + Cs + Cu + Ts + Kus + M + Ps) 
  332.    
  333.    where M is the request shown above, octet by octet, from the type 
  334.    octet for the containing object through the last octet of the length
  335.    field of the As object, inclusive. This serves to protect the entire 
  336.    request, and differs from the calculation in the authentication 
  337.    document by the addition of the message contents as shown. Note that 
  338.    the Nu mentioned as the third component in the formula is the 
  339.    originally specified username, not the altered-case version in the 
  340.    response message. 
  341.  
  342.  
  343. G Brown                                                         [Page 6]
  344.  
  345. INTERNET-DRAFT             RPA - Part Four              15 November 1996
  346.  
  347.    
  348.    Beware that an affirmative response does not necessarily mean that it
  349.    is reasonable to provide service to the user. Often, there are 
  350.    criteria beyond a "yes" answer, which could mean anything from "it's 
  351.    a valid user" to "it's a valid user but not billable" to "it's an 
  352.    account that was signed up five minutes ago and we haven't had a 
  353.    chance to look at it yet." 
  354.    
  355.    Typically, the authentication deity applies criteria appropriate to 
  356.    the requesting service. For example, if the service doesn't want to 
  357.    allow "free" users, the authentication deity would be configured to 
  358.    return a no-service response for such a user. Alternatively, the 
  359.    deity could be configured to provide an affirmative response but 
  360.    include information in the blob that would permit the service to 
  361.    distinguish "free" from "paying" users and treat them differently. 
  362.  
  363.    
  364. 4.3 Authentication response, no service 
  365.    
  366.    The no-service response is an indication that the user is whom he 
  367.    claims to be, but you should not provide service to him for one 
  368.    reason or another. For example, he might be a "free" user but your 
  369.    service is provided only to paying accounts; his billing choices 
  370.    might not include your service; or Customer Service might be waiting
  371.    for him to provide a new credit card number. 
  372.    
  373.    The authentication deity's configuration for this particular service 
  374.    determines the criteria applied by the deity when making the decision
  375.    to reply affirmative or no service. 
  376.    
  377.        Request identifier
  378.        Canonical Nu (User name, case corrected)
  379.        Kuss (Key obscured for service)
  380.        Kusu (Key obscured for user)
  381.        Au (Authentication value for user)
  382.        Blob (optional)
  383.        As (Authentication value for service)
  384.    
  385.    The contents of this object are identical to those for an affirmative
  386.    response, but the service would not normally use the keys or Au 
  387.    values. The blob might include information useful in distinguishing 
  388.    the reason for the no service response, if appropriate for this 
  389.    service. 
  390.  
  391.    
  392. 4.4 Authentication response, negative 
  393.    
  394.    A negative response means the user is not who he says he is. Whether 
  395.    there is such a username, but that's not who you're talking to; there
  396.    is such a username, but it is not an enabled account; or there is no 
  397.    such username, is not specified. 
  398.  
  399.  
  400. G Brown                                                         [Page 7]
  401.  
  402. INTERNET-DRAFT             RPA - Part Four              15 November 1996
  403.  
  404.    
  405.        Request identifier
  406.        Blob (optional)
  407.        As (Authentication value for service)
  408.    
  409.    As is calculated as MD5(Ps + Z + M + Ps). The message may contain a 
  410.    blob if there is additional information about the problem, e.g., for 
  411.    logging, but it may be omitted. 
  412.  
  413.    
  414. 4.5 Authentication response, invalid service 
  415.    
  416.    An invalid request response means the request could not be processed 
  417.    because you (the service) are not whom you claim to be, based on your
  418.    apparently not knowing the service's pass phrase or based on any 
  419.    other kind of authentication checking done by the deity. 
  420.    
  421.        Request identifier
  422.        Blob (optional)
  423.    
  424.    The blob, if present, contains information that allows the deity 
  425.    administrators to trace the problem. There is no As field, because 
  426.    there is no shared secret to authenticate the response. This presents
  427.    some obvious denial of service issues. 
  428.  
  429.    
  430. 4.6 Authentication response, problem 
  431.    
  432.    A "problem" response indicates that the request could not be 
  433.    processed for some reason. This could indicate a failure in the 
  434.    system, an unparsable request, or a request for a realm that isn't 
  435.    handled by this deity. 
  436.    
  437.        Request identifier
  438.        Blob (optional)
  439.        As (optional)
  440.    
  441.    The blob may contain information that allows the deity administrators
  442.    to trace the problem. As might or might not be present, depending on 
  443.    the nature of the problem, i.e., whether there is a known shared 
  444.    secret with the server; if present, it is calculated as MD5(Ps + Z + 
  445.    M + Ps). 
  446.  
  447.  
  448. 5. Object types 
  449.    
  450.    The following types of objects are defined in this protocol. These 
  451.    object types apply to the messages themselves and objects contained 
  452.    in messages. These types do not apply to the contents of the blob. 
  453.  
  454.  
  455.  
  456.  
  457. G Brown                                                         [Page 8]
  458.  
  459. INTERNET-DRAFT             RPA - Part Four              15 November 1996
  460.  
  461.    
  462.         [Numbers for the object type field are indicated for each 
  463.         type, but are not necessarily accurate in this draft of the 
  464.         document.] 
  465.    
  466.    Authentication request--type 1--The request to the authentication 
  467.    deity. Its contents consist of a sequence of other objects as 
  468.    described elsewhere in this document. 
  469.    
  470.    Authentication response, affirmative--type 2 
  471.    
  472.    Authentication response, no service--type 3 
  473.    
  474.    Authentication response, negative--type 4 
  475.    
  476.    Authentication response, invalid service--type 5 
  477.    
  478.    Authentication response, problem--type 6 
  479.    
  480.    Request identifier--type 128--A request must contain an identifier to
  481.    assist in matching replies to requests. This identifier is opaque to 
  482.    the deity, and is simply echoed in the reply, so its value is defined
  483.    only by the requesting entity. The value should, of course, be unique 
  484.    for each request, but it is otherwise meaningless. It may be of any 
  485.    length. 
  486.    
  487.    Realm name--type 129--The name of the realm in which the user's and 
  488.    service's identities exist. This is included in the request to allow 
  489.    a deity to serve more than one realm. The value consists of the name 
  490.    in Unicode, in big-endian order. There is no terminating null 
  491.    character, and the realm is generally treated as being case 
  492.    insensitive. For example, the realm aol.com might look like this: 
  493.    
  494.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  495.    |   10000001    |   00000000    |   00001110    |   00000000    |
  496.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  497.    |   01100001    |   00000000    |   01101111    |   00000000    |
  498.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  499.    |   01101100    |   00000000    |   00101110    |   00000000    |
  500.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  501.    |   01100011    |   00000000    |   01101111    |   00000000    |
  502.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  503.    |   01101101    |
  504.    +-+-+-+-+-+-+-+-+
  505.    
  506.    That's type 129, fourteen octets follow, and the big-endian Unicode 
  507.    representation of the seven characters aol.com. 
  508.    
  509.    Service name--type 130--The name of the service in big-endian 
  510.    Unicode. 
  511.  
  512.  
  513.  
  514. G Brown                                                         [Page 9]
  515.  
  516. INTERNET-DRAFT             RPA - Part Four              15 November 1996
  517.  
  518.    
  519.    User name--type 131--The name of the user in big-endian Unicode, 
  520.    e.g., gsb.
  521.    
  522.    User challenge--type 132--The user's challenge, a sequence of random 
  523.    octets. The length is not bounded by the protocol, but the deity will 
  524.    impose length restrictions, e.g., a minimum and maximum length. All 
  525.    bit patterns are legal in the challenge. 
  526.    
  527.    Service challenge--type 133--The service's challenge, a sequence of 
  528.    random octets. The length is not bounded by the protocol, but the 
  529.    deity will impose length restrictions, e.g., a minimum and maximum 
  530.    length. All bit patterns are legal in the challenge. 
  531.    
  532.    Time stamp--type 134--The time stamp, containing 14 octets with the 
  533.    value specified in part two of this specification
  534.    (draft-petke-mech-00.txt).
  535.    
  536.    User's response--type 135--The user's response, containing 16 octets 
  537.    with the value specified in part two of this specification
  538.    (draft-petke-mech-00.txt). This is a binary value, so any bit pattern
  539.    is possible in this value. 
  540.    
  541.    Service's response--type 136--The service's response, calculated as 
  542.    described elsewhere in this document. This is a binary value, so any 
  543.    bit pattern is possible in this value. 
  544.    
  545.    Key obscured for user--type 137--The key for the user, containing 16 
  546.    octets as described in part two of this specification
  547.    (draft-petke-mech-00.txt). This is a binary value, so any bit pattern
  548.    is possible in this value. 
  549.    
  550.    Key obscured for service--type 138--The key for the service, 
  551.    containing 16 octets as described in part two of this specification
  552.    (draft-petke-mech-00.txt). This is a binary value, so any bit pattern
  553.    is possible in this value. 
  554.    
  555.    Authentication proof for user--type 139--The authentication proof, 
  556.    Au, for the user, containing 16 octets as described in part two of 
  557.    this specification (draft-petke-mech-00.txt). This is a binary value,
  558.    so any bit pattern is possible in this value. 
  559.    
  560.    Authentication proof for service--type 140--The authentication proof,
  561.    As, for the service, containing 16 octets calculated as described 
  562.    elsewhere in this document (not as described in part two of this 
  563.    specification). This is a binary value, so any bit pattern is 
  564.    possible in this value. 
  565.    
  566.    Canonical user name--type 141--The username adjusted to canonical 
  567.    case, in big-endian Unicode. 
  568.  
  569.    Blob--type 142--Deity-specific request and response information. 
  570.  
  571. G Brown                                                        [Page 10]
  572.  
  573. INTERNET-DRAFT             RPA - Part Four              15 November 1996
  574.    
  575.  
  576. 6. The blob 
  577.    
  578.    The blob consists of a sequence of objects that contain information 
  579.    about the user's account, or indicate, by their presence or absence, 
  580.    some characteristic of the user's account. Note that the use of any 
  581.    particular object is a function of the deity's configuration for a 
  582.    particular service. 
  583.    
  584.    Consider, for example, a "free" account in an environment where 
  585.    services are normally provided for a price. There are three 
  586.    most-likely possibilities for how the deity would handle a free 
  587.    account when a particular service asks the deity to authenticate a 
  588.    user: 
  589.    
  590.    * If the account is free, return an affirmative response. 
  591.      
  592.    * If the account is free, return an affirmative response and include
  593.      a "free" indicator in the blob. 
  594.      
  595.    * If the account is free, return a no-service response. 
  596.      
  597.    The first alternative would be appropriate for a service that should 
  598.    provide service to free users, when it's none of the service's 
  599.    business whether the user is paying or not. 
  600.    
  601.    The second alternative would be appropriate for a service that should 
  602.    provide service to free users, but should know that it's doing so, 
  603.    e.g., to provide a different class of service to free users than 
  604.    not-free users. 
  605.    
  606.    The third alternative would be appropriate for a service that should 
  607.    not provide service to free users. In that case, the deity might 
  608.    include a free indicator in the blob, to note the reason why. 
  609.    
  610.    It's difficult to conceive of a truly general, standard blob format; 
  611.    that's why we called it a "blob." Therefor, a service-deity pair may 
  612.    define the blob in any way they wish. However, we define one type of 
  613.    sub-object that contains textual attribute/value pairs, to provide a 
  614.    standard encoding for one common need. 
  615.    
  616.    Type 1--Attribute/value pairs 
  617.    
  618.    If the blob contains a type-1 object, that object is composed of a 
  619.    sequence of textual attribute/value pairs, where the value is 
  620.    optional: sometimes, the presence or absence of an attribute is 
  621.    significant, with no need for a corresponding value. An attribute 
  622.    consists of a sequence of Unicode characters in the syntax 
  623.  
  624.        attribute ["=" value] 
  625.  
  626.  
  627.  
  628. G Brown                                                        [Page 11]
  629.  
  630. INTERNET-DRAFT             RPA - Part Four              15 November 1996
  631.  
  632.    
  633.    i.e., the attribute name optionally followed by an '=' character 
  634.    (code 003D) and a value. All characters are taken from the Unicode 
  635.    character set and stored in big-endian byte order. The attribute name 
  636.    may consist of any characters except a null or equals sign; the value 
  637.    may consist of any characters except a null. 
  638.    
  639.    To include more than one attribute, use a null character (code 0000) 
  640.    as a separator. A null character following the last attribute is 
  641.    optional, and may be omitted. 
  642.    
  643.        L"free\0language=en" 
  644.    
  645.    is a C-syntax example of a pair of attributes, the first with no 
  646.    value. 
  647.    
  648.    Attribute names are meaningful only in the context of a particular 
  649.    service-deity pair. They may be case sensitive or not as appropriate.
  650.    
  651.         [Perhaps there should be two blocks of named attributes, 
  652.         one with standard-defined attributes and one with 
  653.         deity-specific attributes?] 
  654.    
  655.  
  656. 7. Security Considerations 
  657.    
  658.    This entire document is about security. 
  659.    
  660.  
  661. 8. Author's Address 
  662.    
  663.    Gary S. Brown
  664.    CompuServe Incorporated
  665.    5000 Britton Rd
  666.    P.O. Box 5000
  667.    Hilliard OH 43026-5000
  668.    USA
  669.    
  670.    +1 614 723 1127
  671.    <gsb@csi.compuserve.com>
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685. G Brown                                                        [Page 12]
  686.  
  687.  
  688.