[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [KEYPROV] DSKPP - Authn Code Format



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

-----Original Message-----
From: Pei, Mingliang [mailto:mpei at verisign.com] 
Sent: Thursday, May 15, 2008 1:59 PM
To: Doherty, Andrea; keyprov at ietf.org
Subject: RE: [KEYPROV] DSKPP - Authn Code Format


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

> -----Original Message-----
> From: andrea.doherty at rsa.com [mailto:andrea.doherty at rsa.com] 
> Sent: Thursday, May 15, 2008 10:38 AM
> To: Pei, Mingliang; keyprov at ietf.org
> Subject: RE: [KEYPROV] DSKPP - Authn Code Format
> 
> 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:
> 
>       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 
> 
> -----Original Message-----
> From: Pei, Mingliang [mailto:mpei at verisign.com]
> Sent: Thursday, May 15, 2008 1:25 PM
> To: Doherty, Andrea; keyprov at ietf.org
> Subject: RE: [KEYPROV] DSKPP - Authn Code Format
> 
> 
> 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: keyprov-bounces at ietf.org 
> > [mailto:keyprov-bounces at ietf.org] On Behalf Of 
> andrea.doherty at rsa.com
> > Sent: Thursday, May 15, 2008 9:59 AM
> > To: keyprov at ietf.org
> > 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:
> > 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
> > KEYPROV at ietf.org
> > https://www.ietf.org/mailman/listinfo/keyprov
> > 
> 
> 

_______________________________________________
KEYPROV mailing list
KEYPROV at ietf.org
https://www.ietf.org/mailman/listinfo/keyprov