Subject: [KEYPROV] 3.4.2 Auth Code Format - update

From: [email-masked]
Date: Wed, 21 May 2008 14:39:41 -0400

Please review this section and let me know if you have any comments.
This is for inclusion in the 04 draft of DSKPP.  
Thanks,
Andrea

3.4.2.  Authentication Code Format

   AC is encoded in Type-Length-Value (TLV) format.  The format consists
   of a minimum of two TLVs and a variable number of additional TLVs,
   depending on implementation.  See Figure 4 for TLV field layout.

   A 1 byte type field identifies the specific TLV, and a 1 byte length,
   in hexadecimal, indicates the length of the value field contained in
   the TLV.  A TLV MUST start on a 4 byte boundary.  Pad bytes MUST be
   placed at the end of the previous TLV in order to align the next TLV.
   These pad bytes are not counted in the length field of the TLV.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    |    Value[0]   |  ...Value[Length-1]
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 4: TLV Format

   The TLV fields are defined as follows:

   Type (1 byte)             The integer value identifying the type of
                             information contained in the value field.

   Length (1 byte)           The length, in hexadecimal, of the value
                             field to follow.

   Value (variable length)   A variable-length hexadecimal value
                             containing the instance-specific
                             information for this TLV.

   Figure 5 summarizes the TLVs defined in this document.  Optional TLVs
   allow implementation-specific extensions.  Other TLVs are left for
   later revisions of this protocol.

Doherty, et al.         Expires December 1, 2008               [Page 34]

Internet-Draft                    DSKPP                         May 2008

   +------+------------+-------------------------------------------+
   | Type | TLV Name   | Conformance | Example Usage               |
   +------+------------+-------------------------------------------+
   |  1   | Client ID  | Mandatory   | { "AC00000A" }              |
   +------+------------+-------------+-----------------------------+
   |  2   | Password   | Mandatory   | { "3582" }                  |
   +------+------------+-------------+-----------------------------+
   |  3   | Checksum   | Optional    | { 0x5F8D }                  |
   +------+------------+-------------+-----------------------------+
   |  4   | Extension  | Optional    | {"implementation-specific"} |
   +------+------------+-------------+-----------------------------+

                           Figure 5: TLV Summary

3.4.2.1.  Client ID (MANDATORY)

   The Client ID is a mandatory TLV that represents the user's key
   request.  A summary of the Client ID TLV format is given in Figure 6.
   The fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 0x1    |     Length    | Client ID ...                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 6: Client ID TLV Format

   The Client ID is an ASCII string that identifies the key request.
   The identifier MUST be translated to hexadecimal.

   For example, suppose the Client ID is set to "AC00000A", the
   hexadecimal equivalent is 0x4143303030303041, resulting in a TLV of
   {0x1, 0x8, 0x4143303030303041}.

3.4.2.2.  Password (MANDATORY)

   The Password is a mandatory TLV the contains a one-time use shared
   secret known by the user and the Provisioning Server.  A summary of
   the Password TLV format is given in Figure 7.  The fields are
   transmitted from left to right.

Doherty, et al.         Expires December 1, 2008               [Page 35]

Internet-Draft                    DSKPP                         May 2008

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 0x2    |     Length    | Password ...                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 7: Password TLV Format

   The Password is a unique value that SHOULD be a random string to make
   AC more difficult to guess.  The string MUST be translated to
   hexadecimal.

   For example, suppose the Password is set to "3582", the hexadecimal
   equivalent is 0x33353832, resulting in a TLV of {0x2, 0x4,
   0x33353832}.

3.4.2.3.  Checksum (OPTIONAL)

   The Checksum is an OPTIONAL TLV, which is generated by the issuing
   server and sent to the user as part of the AC.  A summary of the
   Checksum TLV format is given in Figure 8.  The fields are transmitted
   from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 0x3    |     Length    | Checksum                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 8: Checksum TLV Format

   If included the checksum MUST be computed using the CRC16 algorithm
   [ISO3309].  When the user enters the AC, the typed password is
   verified with the checksum to ensure it is correctly entered by the
   user.

   For example, suppose the Password is set to "3582", then the CRC16
   calculation would generate a checksum of 0x5F8D, resulting in a TLV
   {0x3, 0x2, 0x5F8D}.

3.4.2.4.  Extension (OPTIONAL)

   This TLV is available to allow implementers to support their own
   extended attributes not suitable for general usage.  The information
   conveyed in the TLV MUST not affect the operation of the DSKPP
   protocol.

   DSKPP servers not equipped to interpret the extension attributes sent

Doherty, et al.         Expires December 1, 2008               [Page 36]

Internet-Draft                    DSKPP                         May 2008

   by the DSKPP client MUST ignore it.  DSKPP servers that do not
   receive a desired extension attribute SHOULD make an attempt to
   operate without it.

   A summary of the Extension TLV format is shown below.  The fields are
   transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 0x4    |     Length    | Extension ...                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 9: Extension TLV Format

   The Extension field is one or more bytes.  The actual format of the
   information is application specific, and a robust implementation
   SHOULD support the field as undistinguished hexadecimal.  Multiple
   sub-attributes MAY be encoded within a single implementation-specific
   TLV, although they do not have to be.

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov