Subject: [KEYPROV] DSKPP - Authn Code Format

From: [email-masked]
Date: Thu, 15 May 2008 12:58:41 -0400

I am adding the Authentication Code Format back into the DSKPP for
version -04 as per comments received on the mailing list and presented
at IETF-71.  Please review this change, which specifies a TLV format as
the required format:
3.4.2. Authentication Code Format 
At a minimum, the AC MUST contain the following parameters: 
identifier: A globally unique client identifier that represents the
user's key request. This value MAY be generated as a sequence number. 
password: A unique value that SHOULD be generated by the system as a
random number to make AC more difficult to guess. 
A checksum element MAY be included, which is generated by the issuing
server and sent to the user as part of the AC. 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. 
The Issuer MUST rely on a Tag-Length-Value (TLV) format to represent the
AC: 
Tag = 0x01 = identifier (MANDATORY) 
Tag = 0x02= password (MANDATORY) 
Tag = 0x03 = checksum (OPTIONAL) 
Tag = 0x04 = [additional parameter] (OPTIONAL) 
... 
Tag = 0x0n = [additional parameter] (OPTIONAL) 
where one byte MUST be used to indicate the L(ength) of the V(alue)
field. 

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

---

From: "Pei, Mingliang" <[email-masked]>
Date: Thu, 15 May 2008 10:24:44 -0700

Hi Andrea,

Thank you for adding it. A few quick comments.

1. On the identifier: I am not sure that the "identifier" must be
"globally" unique. As long as the server can identify it for
authentication purpose, it should be fine, I think. Requiring "global"
uniqueness may impose unnecessary complexity and longer length on the
value.

2. On password: shall we leave it to the provider to make it a random
string that can be alphanumeric instead of "generated random number"? If
it were a number, we better also has a place holder for encoding form
being decimal or hex representation.

Thoughts? Thanks,

- Ming

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, May 15, 2008 9:59 AM
> To: [email-masked]
> Subject: [KEYPROV] DSKPP - Authn Code Format
> 
> I am adding the Authentication Code Format back into the 
> DSKPP for version -04 as per comments received on the mailing 
> list and presented at IETF-71.  Please review this change, 
> which specifies a TLV format as the required format:
> identifier: A globally unique client identifier that 
> represents the user's key request. This value MAY be 
> generated as a sequence number. 
> password: A unique value that SHOULD be generated by the 
> system as a random number to make AC more difficult to guess. 
> A checksum element MAY be included, which is generated by the 
> issuing server and sent to the user as part of the AC. 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. 
> Tag = 0x04 = [additional parameter] (OPTIONAL) ... 
> Tag = 0x0n = [additional parameter] (OPTIONAL) where one byte 
> MUST be used to indicate the L(ength) of the V(alue) field. 
> 
> Andrea

---

From: [email-masked]
Date: Thu, 15 May 2008 13:37:36 -0400

Ming,
Thanks...how does this look?
   At a minimum, the AC MUST contain the following parameters:

   identifier:  A client identifier that represents the user's key
       request.

   password:  A unique value that SHOULD be a random string to make AC
       more difficult to guess.

   A checksum element MAY be included, which is generated by the issuing
   server and sent to the user as part of the AC.  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.

   The Issuer MUST rely on a Tag-Length-Value (TLV) format to represent
   the AC:

Andrea 

-----Original Message-----
From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Thursday, May 15, 2008 1:25 PM
To: Doherty, Andrea; [email-masked]
Subject: RE: [KEYPROV] DSKPP - Authn Code Format

Hi Andrea,

Thoughts? Thanks,

- Ming

---

From: "Pei, Mingliang" <[email-masked]>
Date: Thu, 15 May 2008 10:59:25 -0700

The changes look good to me. Shall we pose an example?

A sample in string representation for ID = "AC000001" and password =
"35824091":

18AC0000012835824091

Needs to show individual byte value for a sample that contains a length
greater than 9.
 
- Ming

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, May 15, 2008 10:38 AM
> To: Pei, Mingliang; [email-masked]

---

From: [email-masked]
Date: Thu, 15 May 2008 14:01:07 -0400

Yes, that is a good idea.  I'll include that.
Andrea 

-----Original Message-----
From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Thursday, May 15, 2008 1:59 PM
To: Doherty, Andrea; [email-masked]
Subject: RE: [KEYPROV] DSKPP - Authn Code Format

18AC0000012835824091

- Ming