[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[KEYPROV] 3.4.2 Auth Code Format - update
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
KEYPROV at ietf.org
https://www.ietf.org/mailman/listinfo/keyprov