Subject: [KEYPROV] FW: DISCUSS and COMMENT: draft-ietf-keyprov-dskpp

From: <[email-masked]>
Date: Mon, 7 Jun 2010 22:15:53 -0400

Fyi re latest discussion with Alexey Melnikov re points he raised during IETF LC.  DISCUSS items where we already have agreement are not shown below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, June 07, 2010 10:01 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: DISCUSS and COMMENT: draft-ietf-keyprov-dskpp

Alexey,

Please see my responses below. 

Regards,
Andrea

>-----Original Message-----
>From: Alexey Melnikov [mailto:[email-masked]] 
>Sent: Wednesday, May 05, 2010 6:12 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: DISCUSS and COMMENT: draft-ietf-keyprov-dskpp 
>
>Discuss:
>[Updated. DISCUSS issues starting from # 17 are new. Comment section is unchanged.]
>
>I would like to discuss the following issues before recommending approval of this document:
>  
>
 [...]

>2)
>3.3.  Status Codes
>
>   NoProtocolVariants:  The DSKPP client only suggested a protocol
>       variant (either 2-pass or 4-pass) that is not supported by the
>       DSKPP server.  This error is only valid in the DSKPP server's
>       first response message
>
>According to Section 9, both variants are MUST implement for the server,
>so this status code can never be returned.
>
>[Doherty, Andrea] Agreed.  While Section 9 calls for the DSKPP server to implement both protocol variants, it only calls for the DSKPP client to implement one or the other.  Here is the specific text that I am referencing:
>   DSKPP clients MUST support either the two-pass or the four-pass
>   variant of the protocol.  DSKPP clients MUST fulfill all requirements
>   listed in item (c) - (j).
>
>   As a result, the XML schema makes optional TwoPass and FourPass (refer to Section 8.2):
>      <xs:complexType name="ProtocolVariantsType">
>         <xs:sequence>
>            <xs:element name="FourPass" minOccurs="0" />
>            <xs:element name="TwoPass" type="dskpp:KeyProtectionDataType"
>               minOccurs="0"/>
>         </xs:sequence>
>      </xs:complexType>
>
>You are right that if the DSKPP client and server are implemented according to spec, the NoProtocolVariants status code, as described, should never be returned.  The reason for having this status code, however, is to stop the protocol from running right at the start if the DSKPP client is in fact not in conformance with the specification.  As the text does not make this clear, I propose to change the text to read:
>
>   NoProtocolVariants:  The DSKPP client did not suggest a required 
>   protocol variant (either 2-pass or 4-pass).  This error is only 
>   valid in the DSKPP server's first response message.
>  
>
This is more useful. Thanks.

[Doherty, Andrea] Thanks; I will update the text using the proposed change above.

>3)
>3.4.1.1.  Authentication Code Format
>
>   Length (1 byte)           The length, in hexadecimal, of the value
>                             field to follow.
>
>1 byte length in hexadecimal? Do you mean the length is restricted to 15 bytes (one hexadecimal character)?
>Or do you mean that the draft displays such values in hexadecimal, i.e. that that is only a display convention?[Doherty, Andrea] 
>
>[Doherty, Andrea] The length is in hex to allow Ids, Passwords, and other vendor-specific attributes to be 15 digits max in length.  I will clarify that in the text, as in "Length is in hexadecimal to allow values to be a maximum of 15 digits in length".

>
>   Value (variable length)   A variable-length hexadecimal value
>                             containing the instance-specific
>                             information for this TLV.
>
>As above.
>
>[Doherty, Andrea] I will change text to state, "A variable-length string value..."
>
>   The Client ID is a mandatory TLV that represents the requester's
>   identifier of maximum length 128.  The value is represented as an
>   ASCII string that identifies the key request.  The ClientID MUST be
>   HEX encoded.  For example, suppose ClientID is set to "AC00000A", the
>   hexadecimal equivalent is 0x4143303030303041, resulting in a TLV of
>   {0x1, 0x8, 0x4143303030303041}.
>  
>
I suggest you don't use "0x" prefix in the last field and use quotes 
around it.

[Doherty, Andrea] Please refer to the attached text, which is how we propose to change Section 3.4.1.1. Our intent is that the new text will, among other things, address the issues raised with respect to the Authentication Code Format.

>I am still confused about use of HEX here.
>
>[Doherty, Andrea] HEX is confusing here, although it was originally intended to add clarity.  Furthermore, note that the example indicates Type as hexadecimal when it is specified as an integer.  As such, I propose to change the text as follows:
>    The Client ID is a mandatory TLV that represents the requester's
>    identifier.  The value is represented as a string that identifies 
>    the key request.  The ClientID MUST be UTF-8 encoded in accordance 
>    with [RFC3629].  The Client ID has a maximum length of 15 bytes 
>    after UTF-8 conversion, i.e, the total number of octets transmitted 
>    to the decoder. For example, suppose ClientID is set to "AC00000A", 
>    then the TLV would be {1, 0x8, UTF-8("AC00000A")}.
>
>Likewise, the description for password should change:
>   The Password is a mandatory TLV the contains a one-time use shared
>   secret known by the user and the Provisioning Server.  The password
>   value is unique and SHOULD be a random string to make AC more
>   difficult to guess.  The string MUST be UTF-8 encoded in accordance
>   with [RFC3629].  The password has a maximum length of 15 bytes 
>   after UTF-8 conversion, i.e, the total number of octets transmitted 
>   to the decoder. For example, suppose password is set to "3582", then
>   the TLV would be {2, 0x4, UTF-8("3582")}.
>  
>
This is better.

But I do think that 15 bytes limit is a bit low.

[Doherty, Andrea]  When using 128 US-ASCII character set, 15 bytes is long enough.   With phone applications it is even longer than most applications would expect. However, when allowing for non-ASCII characters from other languages, 15 bytes will translate to a few printable characters (anywhere between 3 and 7) which may be too short and relatively easier to guess.  Therefore, we will increase the length attribute to 2 bytes (allowing for up to 255 bytes length).

>10)
>3.4.1.1.  Authentication Code Format
>
>   The following table summarizes the TLVs defined in this document.
>   Optional TLVs are allowed for vendor-specific extensions with the
>   constraint that the high bit MUST be set to indicate a vendor-
>   specific type.  Other TLVs are left for later revisions of this
>   protocol.
>
>I think this needs an IANA registry, considering that the value space is only 1 byte.[Doherty, Andrea] 
>
>[Doherty, Andrea] The purpose of the sentence at the end of the paragraph (i.e., "Other TLVs are left for later revisions of this protocol") was to indicate that no IANA registration is required.  Is it not procedurally correct to assume that since we have a versioning mechanism (as defined in Section 1.2), no IANA registration of future tag types is required?
>  
>
You don't have to have an IANA registry, but if you expect more 
registrations, some of them not coming from RFCs (e.g. vendor-specific), 
you should really think hard about creating a new IANA registry.

[Doherty, Andrea] We don't expect more registrations.  If the unexpected happens and more come along, then whoever adds them can define an IANA registry.

>11)
>3.3.  Status Codes
>
>   UnknownCriticalExtension:  A critical DSKPP extension (see below)
>       used by the DSKPP client was not supported or recognized by the
>       DSKPP server
>
>Extension criticality is not discussed in the document (except for having
>"Critical" attribute in the XML Schema).
>
>[Doherty, Andrea] Good catch.  I think that Section 6 requires an update to describe the "Critical" attribute that is in the XML schema.  I propose to add the following text to the end of Section 6:
>
>   "The ExtensionsType type is a list of type-value pairs that define
>   optional features supported by a DSKPP client or server.
>   Extensions may be sent with any DSKPP message. Unless an extension is marked as
>   Critical
>
I think you should mention how this is done in XML, for example by 
adding "(by using the "critical" attribute)".

[Doherty, Andrea] Agree; will add "(by using the "critical" attribute)” after “marked as Critical”.

>13)
>5.1.2.  Key Wrap
>
>   The DSKPP server and client MUST support one of the following key
>   wrapping mechanisms:
>
>If only one of the following is mandatory-to-implement, how can you achieve interoperability?
>
>[Doherty, Andrea] Interoperability is achieved through use of the <SupportedEncryptionAlgorithms> type passed in the <KeyProvClientHello> message.
>  
>
If we pick a random client compliant with this document and a random 
server compliant with this document, they might be unable to talk to 
each other if they don't implement a single mandatory-to-implement 
algorithm. (Note that an actual deployment may choose a different 
mechanism to be used.)

[Doherty, Andrea] I see your point; will change the sentence above from “MUST support one of the following key wrapping mechanisms” to “MUST support all of the following key wrapping mechanisms”.

>14)
>5.2.2.  KeyProvClientHello
>
>      If user authentication passes, the DSKPP server generates a key
>      K_PROV, which MUST consist of two parts of equal length, where the
>      first half constitutes K_MAC and the second half constitutes
>      K_TOKEN, i.e.,
>
>K_PROV is defined in 4.1.2 as:
>
>   K_PROV = DSKPP-PRF(k,s,dsLen), where
>
>       k = R_C (i.e., the secret random value chosen by the DSKPP
>       client)
>
>       s = "Key generation" || K || R_S (where K is the key used to
>       encrypt R_C and R_S is the random value chosen by the DSKPP
>       server)
>
>In the 2-pass mode the client doesn't have access to R_S, so is it omitted from "s" in this case? Please clarify the text if that is the case.
>
>[Doherty, Andrea] K_PROV isn't derived from the formula in section 4.1.2, which pertains to Four Pass Usage. In the two-pass case, K_PROV is solely randomly generated by the server.
>  
>
I think you should explicitly say that in the document.

[Doherty, Andrea] Ok, will add above clarification to the document.

>16)
>5.2.3.  KeyProvServerFinished
>
>          DSKPP Client                         DSKPP Server
>           ------------                         ------------
>                                  <---           KP, MAC, AD
>
> [...]
>
>      Finally, this message MUST include a MAC that the DSKPP client
>      will use for key confirmation.  In addition, this message MUST
>      also include a server authentication MAC (AD) if an existing key
>      is being replaced.  These MACs are calculated as described in the
>      previous section.
>
>So I assume that "MAC" in the <KeyProvServerFinished> message is the MAC
>from Section 5.2.2 calculated using the "MAC 1 computation" constant.
>Where is the the server authentication MAC (calculated using the "MAC 2 computation" constant) is included in the <KeyProvServerFinished> message? 
>
>[Doherty, Andrea] AD is used to carry the server authentication MAC value (using the "MAC 2 ...").
>  
>
I suggest you clarify that. Both are referenced as "MAC", so the text is 
a bit confusing.

[Doherty, Andrea] Ok, will add above clarification to the document.

>18)
>5.1.  Key Protection Methods
>
>   This section introduces three key protection methods for the two-pass
>   variant.  Additional methods MAY be defined by external entities or
>   through the IETF process.
>
>Is a new IANA registry needed for these?
>[Doherty, Andrea] I don't think so since these can be covered by future versions of DSKPP.  Also refer to comment on DISCUSS #10.
>  
>
My answer is as above :-).

[Doherty, Andrea] Same response as above :-)

>20)
>3.4.1.1.  Authentication Code Format
>
>    The Password is a mandatory TLV the contains a one-time use shared
>    secret known by the user and the Provisioning Server.  The password
>    value is unique and SHOULD be a random string to make AC more
>    difficult to guess.  The string MUST be UTF-8 encoded in accordance
>    with [RFC3629].  For example, suppose password is set to "3582", then
>    the TLV would be {0x2, 0x4, UTF-8("3582")}.
>
>If the password is intended to be entered by a human in some sort of UI, then this is missing some text about disallowed Unicode characters and Unicode normalization to be used (e.g. Net-Unicode). 
>
>[Doherty, Andrea] We were trying to avoid getting into application specifics here, leaving it up to the implementers to decide on allowable/non-allowable characters.  The password is part of the Authentication Code, which is used to generate a MAC.  The MAC is passed by the protocol without requiring interpretation.  The password is used by the provisioning server to ensure that the user who entered the password was the same one who was given the rights to be issued a key.  The interpretation of the password is at the application layer, above the DSKPP.
>  
>
I think you still need to provide some recommendations to applications 
running above DSKPP (most likely using "SHOULDs").

[Doherty, Andrea] Please refer to the attached text, which is how we propose to change Section 3.4.1.1. Our intent is that the new text will, among other things, address the issues raised with respect to the Authentication Code Format.

Regards,
Alexey

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 08 Jun 2010 06:21:20 +0200

Hi Andrea & Co,
If you need to update the spec. I would recommend dumping

A.7

   "Application Protocol Data Units, or APDUs) are encrypted withing
    a pre-issued card manufacturer's key and sent directly to the smart
    card chip, allowing secure post-issuance in-the-field provisioning"

This has nothing to do with DSKPP, PSKC, or PKCS #11.
It is in fact a *competing* way of provisioning tokens.

Anders

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