One document matched: draft-hallambaker-wsconnect-00.xml

<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
  <!ENTITY rfc2629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
    <!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
    <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
    <!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
    <!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
    <!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
    <!ENTITY RFC3642 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3642.xml">    
    <!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
    <!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml">
    <!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
    <!ENTITY RFC5395 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5395.xml">
  <!ENTITY RFC4366 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-hallambaker-wsconnect-00" ipr="trust200902">

  <front>
    <title abbrev="Web Services Connect Protocol">Web Services Connect Protocol</title>
    <author fullname="Phillip Hallam-Baker" initials="P. M." surname="Hallam-Baker">
      <organization>Comodo Group Inc.</organization>
      <address>
        <email>philliph@comodo.com</email>
      </address>
    </author>
 
    <date day="17" month="May" year="2013" />

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <abstract>
      <t>
        Many Web Services share a requirement for establishing and maintaining
        a persistent connection between the client and service.
        
      </t>

    </abstract>
  </front>

  <middle>
    <section title="Definitions">
      <section title="Requirements Language">
        <t>
          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
          "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
          document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
        </t>
      </section>

    </section>
    <section title="Purpose">

      
    </section>

    <section title="Omnibroker Connection Maintenance Service">

      <section title="Authentication">
        <t>
          The principle function of the OBP Connection Maintenance Protocol
          is to establish and maintain the cryptographic parameters
          used to authenticate and encrypt
        </t>
        <t>
          The user needs to authenticate the broker service regardless
          of any authentication requirements of the broker.
        </t>
        <section title="Broker Authentication">


          <t>

            The OBP connection maintenance protocol transport MUST provide
            a trustworthy means of verifying the identity of the broker
            (e.g. an Extended Validation SSL certificate).
          </t>
          <t>
            If the device supports a display capability, authentication of the
            device and user MAY be achieved by means of an authentication
            image. Such an authentication image is generated by the broker and
            passed to the client in the OpenResponse message. The user then
            verifies that the image presented on the device display is the same
            as that presented on the account maintenance console.
          </t>

        </section>
        <section title="Device Authentication">
          <t>
            If device authentication is required, the mechanism to be used depends on
            the capabilities of the device, the requirements of the broker and
            the existing relationship between the user and the broker.
          </t>

          <t>
            If the device supports some means of data entry, authentication
            MAY be achieved by entering a passcode into the device that was
            previously delivered to the user out of band.
          </t>
          <t>
            The passcode authentication mechanism allows the device to establish
            a proof that it knows the passcode without disclosing the passcode.
            This property provides protection against Man-In-The-Middle type
            disclosure attacks.
          </t>


        </section>

        <!-- Begin section of automatically generated text
Line wrap = 66
   -->
        <section title="Illustrative example" anchor="ConnectionRequestExample">
          <t>
            Alice is an employee of Example Inc. which runs its own
            local omnibroker service 'example.com'.  
To configure her machine for use
            with this service, Alice contacts her network
            administrator who assigns her the account identifier
            'alice' and obtains a PIN number from the service  
            'Q80370-1RA606-F04B'
          </t>
          <t>
            Alice enters the values 'alice@example.com' and
            'Q80370-1RA606-F04B' into her Omnibroker-enabled  
            Web browser.
          </t>
          
          <t>
            The Web browser uses the local DNS to resolve
            'example.com'
            and establishes a HTTPS connection to the specified IP
             address.
            The client verifies that the certificate presented has
             a valid
            certificate chain to an embedded trust anchor under an  
            appropriate certificate policy (e.g. compliant with
            Extended Validation
            Criteria defined by CA-Browser Forum).
          </t>
          <t>
            Having established an authenticated and encrypted TLS  
            session to the Omnibroker service, the client sends
            an OpenRequest message to begin the process of mutual  
            authentication. This message specifies the
            cryptographic
            parameters supported by the client (Authentication,
            Encryption)
            and a nonce value (Challenge), device identification
            parameters (DeviceID, DeviceURI, DeviceName) and the
            name of the account being requested.
          </t>
          <t>
            The client does not specify the PIN code in the
            request,  
            nor is the request authenticated. Instead the client
            informs
            the server that it has a PIN code that can be supplied
             if
            necessary.  
          </t>
          <figure>
            <artwork>
<![CDATA[Post / HTTP/1.1
Host: example.com
Cache-Control: no-store
Content-Type: Application/json;charset=UTF-8
Content-Length: 470

{
  "OpenRequest": {
    "Encryption": ["HS256",
      "HS384",
      "HS512",
      "HS256T128"],
    "Authentication": ["A128CBC",
      "A256CBC",
      "A128GCM",
      "A256GCM"],
    "Account": "alice",
    "Domain": "example.com",
    "HavePasscode": true,
    "HaveDisplay": true,
    "Challenge": "d2gdVeQesS3UTOgtK4JSEg==",
    "DeviceID": "Serial:0002212",
    "DeviceURI": "http://comodo.com/dragon/v3.4",
    "DeviceName": "Comodo Dragon"}}]]>
            </artwork>
          </figure>

          <t>
            The service receives the request. If the request is
            consistent  
            with the access control policy for the server it
            returns a  
            reply that specifies the chosen cryptographic
            parameters  
            (Cryptographic), responds to the client issued by the  
            client to establish server proof of knowsledge of the
             PIN
            (ChallengeResponse) and issues a challenge to the
            client  
            (Challenge).
          </t>
          <t>
            The cryptographic parameters specify algorithms to be
             used  
            for encryption and authentication, a shared secret and
             a  
            ticket value. Note that while the shared secret is
            exchanged  
            in plaintext form in the HTTP binding, the connection
            protocol MUST provide encryption.
          </t>
          <figure>
            <artwork>
<![CDATA[HTTP/1.1 203 Passcode
Content-Type: application/json;charset=UTF-8
Content-Length: 500

{
  "OpenResponse": {
    "Status": 203,
    "StatusDescription": "Passcode",
    "Cryptographic": [{
        "Secret": "11bmdFi9Et7KIUg8aeN2AQ==",
        "Encryption": "A128CBC",
        "Authentication": "HS256",
        "Ticket":
        "TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
        j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIO
        qPa4oB29dgs/ei6ieINZtmvXNCm2NUkWA=="}],
    "Challenge": "alX8aAWH6acSqO3FTT94HA==",
    "ChallengeResponse": "enT5myMw8w2hV4H32Ntx/g=="}}]]>
            </artwork>
          </figure>

          <t>
            To complete the transaction, the client sends a
            TicketRequest message
            to the serice containing a response to the PIN
            challenge sent by the
            service (ChallengeResponse).
            The TicketRequest message is authenticated under the
            shared secret specified
            in the OpenResponse message.
          </t>

          <figure>
            <artwork>
<![CDATA[Post / HTTP/1.1
Host: example.com
Cache-Control: no-store
Content-Type: Application/json;charset=UTF-8
Content-Length: 78
Content-Integrity:
  mac=cjkMkfnnYP8JYWZAbRLvtpqImmOK3rsrOT1XcvAgHDk=;
  ticket=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
    j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
    oB29dgs/ei6ieINZtmvXNCm2NUkWA==

{
  "TicketRequest": {
    "ChallengeResponse": "TctLOG74cwpm26YNpEibcQ=="}}]]>
            </artwork>
          </figure>


<t>
  If the response to the PIN challenge is correct, the service
  responds
  with a message that specifies a set of cryptographic parameters
   to be
  used to authenticate future interactions with the service
  (Cryptographic)  
  and a set of connection parameters for servers supporting the  
  Query Service (Service).
</t>
  <t>
    In this case the server returns three connections, each
    offering a
    different transport protocol option. Each connection specifies
     its
    own set of cryptographic parameters (or will when the code is
     written
    for that).
  </t>
          <figure>
            <artwork>
<![CDATA[HTTP/1.1 200 Complete
Content-Type: application/json;charset=UTF-8
Content-Length: 1907
Content-Integrity:
  mac=nKhjR1r2eYPga0rmDfHT4HOvgQ+EuUoQPwzIl0btljs=;
  ticket=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
    j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
    oB29dgs/ei6ieINZtmvXNCm2NUkWA==

{
  "TicketResponse": {
    "Status": 200,
    "StatusDescription": "Complete",
    "Cryptographic": [{
        "Protocol": "OBPConnection",
        "Secret": "HQuQg4GkzTwTVoGxar0EXg==",
        "Encryption": "A128CBC",
        "Authentication": "HS256",
        "Ticket":
        "0ulMVMMfY/pLHZ0FlIy2zDnNycYz9Znvs3JJYQGlZ+dWaxMNxm/jLEsJd/
        0qsAc5qp8fjBoMN49V9DkDgM4UYJxVriqfr64RyTTgug2taHY="}],
    "Service": [{
        "Name": "obp1.example.com",
        "Port": 443,
        "Address": "10.1.2.3",
        "Priority": 1,
        "Weight": 100,
        "Transport": "WebService",
        "Cryptographic": {
          "Protocol": "OBPQuery",
          "Secret": "kezeXxhkzXgxY7vpkHUb1g==",
          "Encryption": "A128CBC",
          "Authentication": "HS256",
          "Ticket":
          "jpBXvI7/0WTmwI2NN4n7Vvw96nbS9LpSsSNMIkdapiUoLikSkjpgMrtb
          VKz5lHOPloCgAyZXxfZpQRsp4oPY4BcRaMw6F5na62IHnBVDeXg="}},
      {
        "Name": "dns1.example.com",
        "Port": 53,
        "Address": "10.1.2.2",
        "Priority": 1,
        "Weight": 100,
        "Transport": "DNS",
        "Cryptographic": {
          "Protocol": "OBPQuery",
          "Secret": "Wk3m7DlL/GStBBm3xUjyzg==",
          "Encryption": "A128CBC",
          "Authentication": "HS256",
          "Ticket":
          "Q9r4hXefHhLvgpKHVg3w2p7VptVH9qidGiIa4Nw3Zp5hZR816h9+PRj5
          sye1jmIhy4sYA/jfK/g4OrSngK9xWO7Qg3/iQ+YTAchKQjdJtN4="}},
      {
        "Name": "udp.example.com",
        "Port": 5000,
        "Address": "10.1.2.2",
        "Priority": 1,
        "Weight": 100,
        "Transport": "UDP",
        "Cryptographic": {
          "Protocol": "OBPQuery",
          "Secret": "wBiguG9FGj08nS/c/njp4Q==",
          "Encryption": "A128CBC",
          "Authentication": "HS256",
          "Ticket":
          "F8LPKTL+XaAX0eJsM22fdJ37BRS816dKXD66UbD8NAVKOgOu556uS8WW
          AMj+dJbJaErUzo/vw7tY0icCu1bw8qHmOO4gzhbSbD4Nga2EAU4="}}]}
          }]]>
            </artwork>
          </figure>

          <t>
            When Alice's machine is to be transfered to another
            employee, the  
            Unbind transaction is used. The only parameter
            is the
            Ticket identifying the device association (Ticket).
          </t>
          <figure>
            <artwork>
<![CDATA[Post / HTTP/1.1
Host: example.com
Cache-Control: no-store
Content-Type: Application/json;charset=UTF-8
Content-Length: 25
Content-Integrity:
  mac=bZU61eCOW4nVnfdJNS719HL4IsNVxtoTgoRt+mqLbWY=;
  ticket=0ulMVMMfY/pLHZ0FlIy2zDnNycYz9Znvs3JJYQGlZ+dWaxMNxm/jLEsJd/
    0qsAc5qp8fjBoMN49V9DkDgM4UYJxVriqfr64RyTTgug2taHY=

{
  "UnbindRequest": {}}]]>
            </artwork>
          </figure>

          <t>
            Since the unbind response represents the termination
            the
            relationship with the Omnibroker, the response merely
             reports
            the success or failure of the request.
          </t>
          <figure>
            <artwork>
<![CDATA[HTTP/1.1 0  
Content-Type: application/json;charset=UTF-8
Content-Length: 26
Content-Integrity:
  mac=9P1FmroeFU7y9qHgXdSFXH2qSImh0cQpaSgZrx5IswM=;
  ticket=0ulMVMMfY/pLHZ0FlIy2zDnNycYz9Znvs3JJYQGlZ+dWaxMNxm/jLEsJd/
    0qsAc5qp8fjBoMN49V9DkDgM4UYJxVriqfr64RyTTgug2taHY=

{
  "UnbindResponse": {}}]]>
            </artwork>
          </figure>

          <t>
            The 'Ticket' value presented in the foregoing examples
             is  
            a sequence of binary data generated by the service
            is
            opaque to the client. Services MAY generate ticket
            values  
            with a substructure that enable the service to avoid
            the need to maintain server side state.
          </t>
        <t>
          In the foregoing example, the ticket structures generated
          by the service encode the cryptographic parameter data,
          the shared secret, account identifier and an
          authentication  
          value. The initial ticket value generated additionally
          encodes
          the values of the client and service challeng values for
           use
          in calculating the necessary ChallengeResponse.
          </t>
      
        </section>

<!-- End section of automatically generated text -->

      </section>

      



<section title="OBPConnection">


<section title="Message: Message">


<!-- No parameters -->

</section>
<section title="Message: Response">


<t> <list style="hanging" hangIndent="6">
<t hangText="Status : Integer [0..1]   " />
<t>
Application layer server status code
</t>
<t hangText="StatusDescription : String [0..1]   " />
<t>
Describes the status code (ignored by processors)
</t>
</list></t>

</section>
<section title="Message: ErrorResponse">

<t>
An error response MAY be returned in response to any request.
</t>
<t>
Note that requests MAY be rejected by the code implementing
the transport binding before application processing begins
and so a server is not guaranteed to provide an error response
message.
</t>

<!-- No parameters -->

</section>
<section title="Message: Request">


<t> <list style="hanging" hangIndent="6">
<t hangText="Ticket : Binary [1..1]   " />
<t>
Opaque ticket issued by the server that identifies
the cryptographic parameters for encryption and
authentication of the message payload.
</t>
</list></t>

</section>
<section title="Structure: Cryptographic">

<t>
Parameters describing a cryptographic context.
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="Protocol : Label [0..1]   " />
<t>
OBP tickets MAY be restricted to use with either the management
protocol (Management) or the query protocol (Query). If so a 
service would typically 
specify a ticket with a long expiry time or no expiry for use with 
the management protocol and a separate ticket for use with the 
query protocol.
</t>
<t hangText="Secret : Binary [1..1]   " />
<t>
Shared secret
</t>
<t hangText="Encryption : Label [1..1]   " />
<t>
Encryption Algorithm selected
</t>
<t hangText="Authentication : Label [1..1]   " />
<t>
Authentication Algorithm selected
</t>
<t hangText="Ticket : Binary [1..1]   " />
<t>
Opaque ticket issued by the server that identifies
the cryptographic parameters for encryption and
authentication of the message payload.
</t>
<t hangText="Expires : DateTime [0..1]   " />
<t>
Date and time at which the context will expire
</t>
</list></t>

</section>
<section title="Structure: ImageLink">


<t> <list style="hanging" hangIndent="6">
<t hangText="Algorithm : Label [0..1]   " />
<t>
Image encoding algorithm (e.g. JPG, PNG)
</t>
<t hangText="Image : Binary [0..1]   " />
<t>
Image data as specified by algorithm
</t>
</list></t>

</section>
<section title="Structure: Connection">

<t>
Contains information describing a network connection.
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="Name : Name [0..1]   " />
<t>
DNS Name. Since one of the functions of an OBP service is name
resolution, a DNS name is only used to establish a connection if
connection by means of the IP address fails.
</t>
<t hangText="Port : Integer [0..1]   " />
<t>
TCP or UDP port number.
</t>
<t hangText="Address : String [0..1]   " />
<t>
IPv4 (32 bit) or IPv6 (128 bit) service address
</t>
<t hangText="Priority : Integer [0..1]   " />
<t>
Service priority. Services with lower priority numbers SHOULD
be attempted before those with higher numbers.
</t>
<t hangText="Weight : Integer [0..1]   " />
<t>
Weight to be used to select between services of equal priority.
</t>
<t hangText="Transport : Label [0..1]   " />
<t>
OBP Transport binding to be used valid values are HTTP, DNS and UDP.
</t>
<t hangText="Expires : DateTime [0..1]   " />
<t>
Date and time at which the specified connection context will expire.
</t>
</list></t>

</section>
<section title="Bind">

<t>
Binding a device is a two step protocol that begins with the
Start Query followed by a sequence of Ticket queries.
</t>

</section>
<section title="Message: BindRequest">

<t>
The following parameters MAY occur in either a
StartRequest or TicketRequest:
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="Encryption : Label [0..Many]   " />
<t>
Encryption Algorithm that the client accepts. A Client MAY
offer multiple algorithms. If no algorithms are specified then
support for the mandatory to implement algorithm is assumed.
Otherwise mandatory to implement algorithms MUST be 
specified explicitly.
</t>
<t hangText="Authentication : Label [0..Many]   " />
<t>
Authentication Algorithm that the client accepts.
If no algorithms are specified then
support for the mandatory to implement algorithm is assumed.
Otherwise mandatory to implement algorithms MUST be 
specified explicitly. 
</t>
</list></t>

</section>
<section title="Message: BindResponse">

<t>
The following parameters MAY occur in either a
StartResponse or TicketResponse:
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="Cryptographic : Cryptographic [0..Many]   " />
<t>
Cryptographic Parameters.
</t>
<t hangText="Service : Connection [0..Many]   " />
<t>
A Connection describing an OBP service point
</t>
</list></t>

</section>
<section title="Message: OpenRequest">

<t>
The OpenRequest Message is used to begin a device binding transaction.
Depending on the authentication requirements of the service the
transaction may be completed in a single query or require a 
further Ticket Query to complete.
</t>
<t>
If authentication is required, the mechanism to be used depends on
the capabilities of the device, the requirements of the broker and
the existing relationship between the user and the broker.
</t>
<t>
If the device supports some means of data entry, authentication 
MAY be achieved by entering a passcode previously delivered out
of band into the device.
</t>
<t>
The OpenRequest specifies the properties of the service
(Account, Domain) and Device (ID, URI, Name) that will remain
constant throughout the period that the device binding is active
and parameters to be used for the mutual authentication protocol.
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="Account : String [0..1]   " />
<t>
Account name of the user at the OBP service
</t>
<t hangText="Domain : Name [0..1]   " />
<t>
Domain name of the OBP broker service
</t>
<t hangText="HavePasscode : Boolean [0..1]  Default =False " />
<t>
If 'true', the user has entered a passcode value for 
use with passcode authentication.
</t>
<t hangText="HaveDisplay : Boolean [0..1]  Default =False " />
<t>
Specifies if the device is capable of displaying information
to the user or not.
</t>
<t hangText="Challenge : Binary [0..1]   " />
<t>
Client challenge value to be used in authentication challenge
</t>
<t hangText="DeviceID : URI [0..1]   " />
<t>
Device identifier unique for a particular instance of a device such as a MAC or EUI-64 address expressed as a URI
</t>
<t hangText="DeviceURI : URI [0..1]   " />
<t>
Device identifier specifying the type of device, e.g. an xPhone.
</t>
<t hangText="DeviceName : String [0..1]   " />
<t>
Descriptive name for the device that would distinguish it 
from other similar devices, e.g. 'Alice's xPhone".
</t>
</list></t>

</section>
<section title="Message: OpenResponse">

<t>
An Open request MAY be accepted immediately or be held pending
completion of an inband or out-of-band authentication process.
</t>
<t>
The OpenResponse returns a ticket and a set of cryptographic
connection parameters in either case. If the 
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="Challenge : Binary [0..1]   " />
<t>
Challenge value to be used by the client to respond
to the server authentication challenge.
</t>
<t hangText="ChallengeResponse : Binary [0..1]   " />
<t>
Server response to authentication challenge by the client
</t>
<t hangText="VerificationImage : ImageLink [0..Many]   " />
<t>
Link to an image to be used in an image verification mechanism.
</t>
</list></t>

</section>
<section title="Message: TicketRequest">

<t>
The TicketRequest message is used to (1) complete a binding request
begun with an OpenRequest and (2) to refresh ticket or connection 
parameters as necessary.
</t>

<t> <list style="hanging" hangIndent="6">
<t hangText="ChallengeResponse : Binary [0..1]   " />
<t>
The response to a server 
authentication challenge.
</t>
</list></t>

</section>
<section title="Message: TicketResponse">

<t>
The TicketResponse message returns cryptographic and/or connection
context information to a client.
</t>

<!-- No parameters -->

</section>
<section title="Unbind">

<t>
Requests that a previous device association be deleted.
</t>

</section>
<section title="Message: UnbindRequest">

<t>
Since the ticket identifies the binding to be deleted, the
only thing that the unbind message need specify is that
the device wishes to cancel the binding.
</t>

<!-- No parameters -->

</section>
<section title="Message: UnbindResponse">

<t>
Reports on the success of the unbinding operation.
</t>
<t>
If the server reports success, the client SHOULD delete the
ticket and all information relating to the binding.
</t>
<t>
A service MAY continue to accept a ticket after an unbind request
has been granted but MUST NOT accept such a ticket for
a bind request.
</t>

<!-- No parameters -->

</section>

</section>



    </section>
    
    <section title="Mutual Authentication" anchor="MutualAuth">
      <t>
        A Connection Service MAY require that a connection
        request be  
        authenticated. Three authentication mechanisms are
        defined.
      </t>
      <t>
        <list>
          <t>
            PIN Code: The client and server demonstrate mutual
            knowledge of
            a PIN code previously exchanged out of band.
          </t>
          <t>
            Established Key: The client and server demonstrate
            knowledge of the
            private key associated with a credential previously  
            established. This MAY be a public key or a symmetric
             key.
          </t>
          <t>
            Out of Band Confirmation: The request for access is  
            forwarded to an out of band confirmation service.
          </t>
        </list>
      </t>
    
      <section title="PIN Authentication" anchor="ChallengeResponse">

        <t>
          [Motivation]
        </t>
        <t>
          Although the PIN value is never exposed on the wire in
           any form,
          the protcol considers the PIN value to be a text
          encoded  
          in UTF8 encoding.
        </t>
        <t>
          [Considerations for PIN character set choice discussed
           in body
          of draft, servers MUST support numeric only, clients
          SHOULD  
          support full Unicode]
        </t>
        <t>
          The PIN Mechanism is a three step process:
        </t>
        <t>
          <list>
            <t>
              The client sends an OpenRequest message to the
              Service containing  
              a challenge value CC.
            </t>
            <t>
              The service returns an OpenResponse message
              containing to the client a server
              challenge value SV and a server response value SR.
            </t>
            <t>
              The client sends a TicketRequest message to the
              service containing
              a client response value CR.
            </t>
          </list>
        </t>
        <t>
          Since no prior authentication key has been
          the  
          OpenRequest and OpenResponse messages are initially
          sent without  
          authentication and authentication values established
          the
          Challenge-Response mechanism.
        </t>
        <t>
          The Challenge values CC,  and SC are cryptographic
          nonces. The nonces  
          SHOULD be generated using an appropriate cryptographic
           random
          source. The nonces MUST be at least as long as 128
          bits, MUST be at least  
          the minimum key size  
          of the authentication algorithm used and MUST NOT more
           than 640 bits  
          in length (640 bits should be enough for anybody).
        </t>
        <t>
          The server response and client response values are
          generated
          using an authentication algorithm selected by the
          server from the
          choices proposed by the client in the OpenRequest
          message.
        </t>
        <t>
          The algorithn chosen may be a MAC algorithm or an  
          encrypt-with-authentication (EWA) algorithm. If an EWA
           is specified,  
          the encrypted data is discarded and only the
          authentication  
          value is used in its place.
        </t>
        <t>
          Let A(d,k) be the authentication value obtained by
          applying the  
          authentication algorithm with key k to data d.
        </t>
        <t>
          To create the Server Response value, the UTF8 encoding
           of the
          PIN value 'P' is  
          first converted into a symmetric key KPC by using the
           Client
          challenge value as the key
          truncating if necessary and then applied to the
          of the
          OpenRequest message:
        </t>
        <t>
          KPC = A (PIN, CC)
          SR = A (Secret + SC + OpenRequest, KPC)
        </t>
        <t>
          In the Web Service Binding, the Payload of the message
           is the  
          HTTP Body as presented on the wire. The Secret and
          Server  
          Challenge are presented in their
          binary format and the '+' operator stands for simple
          concatenation
          of the binary sequences.
        </t>
        <t>
          This protocol construction ensures that the party
          constructing
          SR:
        </t>
        <t>
          <list>
            <t>
              Knows the PIN code value (through the construction
               of KPC).
            </t>
            <t>
              Is responding to the Open Request Message (SR
              depends on  
              OpenRequest).
            </t>
            <t>
              Has knowlege of the secret key which MUST be used
               to  
              authenticate the following
              TicketRequest/TicketResponse
              interaction that will establish the actual
              connection.
            </t>
            <t>
              Does not provide an oracle the PIN value. That is,
               the protocol  
              does not provide a service that reveals the (since
               the value SR
              includes the value SC which is a random nonce
              generated
              by the server and cannot be predicted by the
              client).
            </t>
          </list>
        </t>

        <t>
          To create the Client Response value, secret key is
          applied  
          to the PIN value and server Challenge:
        </t>
        <t>
          CR = A (PIN + SC + OpenRequest, Secret)
        </t>
                <t>
          Note that the server can calculate the value of the
          Client Response
          token at the time that it generates the Server
          Challenge.
          This minimizes the amount of state that needs to be
          carried from  
          one request to the next in the Ticket value when using
           the stateless
          server implementation described in section <xref target="stateless" />
        </t>
        <t>
          This protocol construction ensures that the
          of CR
        </t>
        <t>
          <list>
            <t>
              Knows the PIN value.
            </t>
            <t>
              Is respoding to the OpenResponse generated by the
               server.
            </t>
          </list>
        </t>
        <t>
          Note that while disclosure of an oracle for the PIN
          value is a  
          concern in the  
          construction of CR, this is not the case in the
          construction of  
          SR since the client has already demonstrated knowledge
           of the  
          PIN value.
        </t>

        </section>

        <section title="Example: Latin PIN Code">
          <t>
            The Connection Request example of section  
            <xref target="ConnectionRequestExample" />
            demonstrates the use
            of an alphanumeric PIN code using the Latin alphabet.
          </t>
          <t>
            The PIN code is [] and the authentication algorithm
             is [].
            The value KP is thus:
          </t>
          <t>
            [TBS]
          </t>
          <t>
            The data over which the hash value is calulated is
            Secret + SC + OpenRequest:
          </t>
          <t>
            [TBS]
          </t>
          <t>
            Applying the derrived key to the data produces the
            server  
            response:
          </t>
          <t>
            The data for the client response is PIN + SC:
          </t>
          <t>
            [TBS]
          </t>
          <t>
            Applying the secret key to the data produces the
            client
            response:
          </t>
          <t>
            [TBS]
          </t>
        </section>
        <section title="Example: Cyrillic PIN Code">
          <t>
            If the PIN code in the earlier example was [] the
            value KP would be:
          </t>
          <t>
            [TBS]
          </t>           
          <t>
            The Server Response would be:
          </t>
          <t>
            [TBS]
          </t>
          <t>
            The rest of the protocol would then continue as
            before.
          </t>
        </section>
      <section title="Stateless server" anchor="stateless">
        <t>
          The protocol is designed to permit but not require a
          stateless
          implementation by the server using the Ticket value
          generated by the  
          server to pass state from the first server transaction
           to the
          second.
        </t>
        <t>
          In the example shown in <xref target="ConnectionRequestExample" />,  
        the server generates a 'temporary ticket' containing the  
        following information:
        </t>

        <t>
          If a server uses the Ticket to transmit state in this
           way it
          MUST protect the confidentiality of the ticket using a
           strong
          means of encryption and authentication.
         </t>
      </section>
      <section title="Established Key" anchor="PublicKeyAuth">
        <t>
          The Established Key mechanism is used when the parties
           have
          an existing shared key or public key credential.
        </t>
        <t>
          The  
          [Open request open response are authenticated under the
          respective keys]
        </t>
        <t>
          SR=CC, CR=SC
        </t>
      </section>
      <section title="Out of Band Confirmation" anchor="OOBConfirmation">
        <t>
          The Out Of Band Confirmation mechanism is a three step  
          process in which:
        </t>
        <t>
          <list>
            <t>
              The client makes an OpenRequest message to the
              service
              and obtains an OpenResponse message.
            </t>
            <t>
              The service is informed that the service has been
              authorized through an out of band process.
            </t>
            <t>
              The client makes a TicketRequest to the service
              and obtains a TicketResponse message to complete  
              the exchange.
            </t>
          </list>
        </t>
        <t>
          Since no prior authentication key has been
          the  
          OpenRequest and OpenResponse messages are sent without  
          authentication.
        </t>
        <t>
          The principal concern in the Out Of Band Confirmation  
          mechanism is ensuring that the party authorizing the
          request is able to identify which party originated
          the request they are attempting to identify.
        </t>
        <t>
          If a device has the ability to display an image it
          MAY set the HasDisplay=true in the OpenRequest message.
          If the broker recieves an OpenRequest with the
          HasDisplay
          value set to true, the OpenResponse MAY contain one or
           more
          VerificationImage entries specifying image data that
          is
          to be displayed to the user by both the client and the
          confirmation interface.
        </t>
        <t>
          Before confirming the request, the user SHOULD verify  
          that the two images are the same and reject the request
          in the case that they are not.
        </t>
        <t>
          Many devices do not have a display capability, in
          particular
          an embedded device such as a network switch or a
          thermostat.
          In this case the device MAY be identified by means of
           the
          information provided in  
          DeviceID, DeviceURI, DeviceImage and DeviceName.
        </t>
      </section>
    </section>



    <section title="Acknowledgements">
      <t>
        [List of contributors]
      </t>
    </section>
    <section title="Security Considerations">

      <section title="Denial of Service">
      </section>
      <section title="Breach of Trust">
      </section>
      <section title="Coercion">
      </section>

    </section>
    <section title="To do">
      <t>

        <list>
          <t>Formatting of the abstract data items needs to be improved</t>
        </list>
      </t>
    </section>

    <section title="IANA Considerations">
      <t>
        [TBS list out all the code points that require an IANA
        registration]
      </t>
    </section>

  </middle>



  <back>


    <references title="Normative References">
      &RFC1035;
      &RFC2119;
      &RFC4366;

      <reference anchor="X.509">
        <front>
          <title>
            ITU-T Recommendation X.509 (11/2008): Information
            technology - Open systems interconnection - The
            Directory: Public-key and attribute certificate
            frameworks
          </title>
          <author>
            <organization>
              International Telecommunication Union
            </organization>
          </author>
          <date month="November" year="2008" />
        </front>
        <seriesInfo name="ITU-T Recommendation" value="X.509" />
        <format type="HTML" target="http://www.itu.int/itu-t/recommendations/rec.aspx?rec=X.509" />
      </reference>
      <reference anchor="X.680">
        <front>
          <title>
            ITU-T Recommendation X.680 (11/2008): Information
            technology - Abstract Syntax Notation One (ASN.1):
            Specification of basic notation
          </title>
          <author>
            <organization>
              International Telecommunication Union
            </organization>
          </author>
          <date month="November" year="2008" />
        </front>
        <seriesInfo name="ITU-T Recommendation" value="X.680" />
        <format type="HTML" target="http://www.itu.int/itu-t/recommendations/rec.aspx?rec=X.680" />
      </reference>

    </references>
    <!--<references title="Non Normative References">

        </references>-->

    <section title="Example Data.">
      <t>

      </t>
      <section title="Ticket A">
        <t>

        </t>
      </section>
      <section title="Ticket B">
        <t>

        </t>
      </section>
    </section>

  </back>
</rfc>