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

["Philip Hoyer" <[e-mail]>]

Andrea,
Just wondering if

urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256

Might not be better expressed as

urn:ietf:params:xml:ns:keyprov:dskpp:prf:aes-128
urn:ietf:params:xml:ns:keyprov:dskpp:prf:sha256

And maybe the 

> URNs: urn:ietf:params:xml:schema:keyprov:dskpp:transport 
> urn:ietf:params:xml:schema:keyprov:dskpp:wrap 
> urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap

urn:ietf:params:xml:schema:keyprov:dskpp:wrap:transport
urn:ietf:params:xml:schema:keyprov:dskpp:wrap:simple
urn:ietf:params:xml:schema:keyprov:dskpp:wrap:passphrase

you know to distinguish the URNs directly.

I also agree with Peter that for interoperability we might need to
mandate that DSKPP server MUST implement a HTTP binding of DSKPP.

Philip

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Monday, June 14, 2010 6:14 PM
To: [e-mail]
Subject: [KEYPROV] FW: DISCUSS and COMMENT: draft-ietf-keyprov-dskpp

All,
Here is feedback that I received from Peter Saint-Andre regarding my
point-to-point responses to him of last week.
Andrea
 

-----Original Message-----
From: Peter Saint-Andre [mailto:[e-mail]] 
Sent: Wednesday, June 09, 2010 12:05 AM
To: Doherty, Andrea
Cc: [e-mail]; [e-mail];
[e-mail]
Subject: Re: DISCUSS and COMMENT: draft-ietf-keyprov-dskpp

On 6/8/10 11:28 AM, [e-mail] wrote:
> Peter,
> 
> Thank you for your thoughtful and thorough review.  Below please find
> point-by-point responses.
> 
> Regards, Andrea
> 
> -----Original Message----- From: Peter Saint-Andre
> [mailto:[e-mail]] Sent: Wednesday, May 05, 2010 11:32 PM 
> To: [e-mail] Cc: [e-mail];
> [e-mail] Subject: DISCUSS and COMMENT:
> draft-ietf-keyprov-dskpp
> 
> Discuss: 1. The defined and referenced identifiers are described as
> URIs of the form xmlns:foo="someUri" and each identifier specifies a
> prefix such as "foo". For example:
> 
> The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is:
> 
> xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
> 
> References to qualified elements in the DSKPP schema defined herein 
> use the prefix "dskpp".
> 
> The URI here is "urn:ietf:params:xml:ns:keyprov:dskpp" without the
> "xmlns:dskpp=" preceding the URI so to reduce confusion it would be
> best to include only the URI. Also, is the prefix "dskpp" hardcoded,
> or are developers allowed to use any prefix? The point of XML
> namespaces was not to hardcode prefixes, so it would be best to say
> that the "dskpp" prefix is used in examples here but any prefix is
> allowed.
> 
> [Doherty, Andrea] Agree; will reword to state:
> 
> The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is:
> 
> "urn:ietf:params:xml:ns:keyprov:dskpp"
> 
> References to qualified elements in the DSKPP schema defined herein 
> use the prefix "dskpp", but any prefix is allowed.

Good.

> 2. In Section 2.1, the Authentication Code is defined as follows:
> 
> Authentication Code (AC):  User Authentication Code comprised of a 
> string of numeric characters known to the device and the server and
> containing a client identifier and a password.  This 
> ClientID/password combination is used only once, and then discarded.
> 
> However, in Section 3.4.1.1 the Authentication Code format does not
> seem to be strictly numeric, because it is a series of
> Type-Length-Value triads encoded as hexadecimal.
> 
> [Doherty, Andrea] Yes, there are inconsistencies between how the
> Authentication Code was defined (Section 2.1), and how it was being
> used (Section 3.4.1.1).  Please refer to the attached text, which is
> how we propose to change these sections to address this issue.

That text is excellent. I especially appreciate the detailed examples.

> 3. In Section 3.4.1.1, the Password TLV is defined as follows:
> 
> 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")}.
> 
> Does the Password really need to be UTF-8? Is it expected that
> characters outside the US-ASCII range will be used? Given that the
> next paragraph talks about "the typed password", this document seems
> to assume that a user will input this password using a keyboard. Can
> we safely assume that a user will be able to input any UTF-8
> character, such as U+233B4 (from RFC 3629)? To ensure that the
> user-typed password matches what is on file at the Provisioning
> Server, this document might need to specify normalization of the
> typed password using Net-Unicode, SASLprep, or some other string
> preparation technology.
> 
> [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 issue raised here with respect
> to the Password TLV.  

Your proposed text addresses my concerns.

> In addition to the attached text, I'll add
> draft-resman-idna2008-mappings-01 as an informative reference and
> insert the correct ref# in the text.

OK. I need to think a bit about whether the mappings in that document
are always desirable for your usage. Consider, for example, the mapping
of upper case characters to lower case characters (which makes sense for
domain names but not necessarily for client IDs or passwords).

> 4. In Section 5.1.2, the key wrapping algorithms are confusingly
> identified, because it appears on a cursory reading that "KW-AES128
> without padding" and "KW-AES128 with padding" have the same
> identifier, when in fact they are identified by id-aes128-wrap and
> id-aes128-wrap-pad respectively in
> draft-housley-aes-key-wrap-with-pad-02.
> 
> [Doherty, Andrea] Yes, the references in this section are incorrect.
> This is easier to reconcile now that the originally referenced I-D is
> an RFC (#3394) and since the latest version of XML Encryption now
> includes a reference to this RFC.  XMLENC is, however, a normative
> reference, and the version that references id-aes128-wrap-pad is a
> Working Draft, due out of W3C LC June 10 (Candidate Draft not ready
> until the Fall of 2010).  As such, here's how I propose to change the
> text:
> 
> AES128 KeyWrap - refer to id-aes128-wrap in [RFC5649] and
> http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
> 
> AES128 KeyWrap with Padding - refer to id-aes128-wrap-pad in
> [RFC3394] and http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
> 
> AES-CBC-128 - refer to [FIPS197-AES] and
> http://www.w3.org/2001/04/xmlenc#aes128-cbc in [XMLENC]

That's better.

> 5. Appendices D.2.1 and D.3.1 define the following algorithm
> identifiers:
> 
> http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128 
> http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256
> 
> It's not clear what the IETF policy is on the use of ietf.org URIs as
> identifiers, but these URIs appear to be used without authorization.
> 
> [Doherty, Andrea] Agree; will switch these to URNs in the keyprov
> parameters space and ask IANA to create a sub registry for each.  The
> URNs will appear as: 
> urn:ietf:params:xml:ns:keyprov:dskpp#dskpp-prf-aes-128 
> urn:ietf:params:xml:ns:keyprov:dskpp#dskpp-prf-sha256

I'm sorry, but now we have a second issue: as I have recently
discovered, the '#' character is not recommended in URNs, see Section
2.3.2 of RFC 2141:

   RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
   purposes. The URN-WG has not yet debated the applicability and
   precise semantics of those purposes as applied to URNs. Therefore,
   these characters are RESERVED for future developments.  Namespace
   developers SHOULD NOT use these characters in unencoded form, but
   rather use the appropriate %-encoding for each character.

Thus I would suggest the following:

   urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
   urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256

> 6. Section 5 mentions a URN of
> urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer as defined in [PSKC]
> but that URN is not to be found in
> draft-ietf-keyprov-portable-symmetric-key-container-03
> 
> [Doherty, Andrea] Thanks for catching this.  The PSKC authors have
> agreed to register a new URN for KeyContainer in the soon next draft
> of the PSKC I-D.  Note also that I will update the reference to PSKC
> accordingly.

And note also that the same issue with the '#' character applies here.
I've followed up with the PSKC authors about that.

> 7. Several URNs containing fragment identifiers are defined in
> Sections 5.1.1, 5.1.2, and 5.1.3:
> 
> urn:ietf:params:xml:schema:keyprov:dskpp#transport 
> urn:ietf:params:xml:schema:keyprov:dskpp#wrap 
> urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap
> 
> However, the "#" character is discouraged in URNs according to RFC
> 2141:
> 
> RFC 1630 [2] reserves the characters "/", "?", and "#" for
> particular purposes. The URN-WG has not yet debated the applicability
> and precise semantics of those purposes as applied to URNs.
> Therefore, these characters are RESERVED for future developments.
> Namespace developers SHOULD NOT use these characters in unencoded
> form, but rather use the appropriate %-encoding for each character.
> 
> Therefore it seems preferable to change "#" to ":" (or some other
> non-reserved character) in these URNs.
> 
> [Doherty, Andrea] Agree; will change "#" to ":" in the following
> URNs: urn:ietf:params:xml:schema:keyprov:dskpp:transport 
> urn:ietf:params:xml:schema:keyprov:dskpp:wrap 
> urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap

Thanks. See above.

> 8. Given that "the principal syntax is XML", a normative reference to
> http://www.w3.org/TR/2006/REC-xml-20060816 is needed.
> 
> [Doherty, Andrea] Agree; will add a normative reference to [XML].
> Note that I'll update the reference to point to the latest published
> version of the W3C Recommendation,
> http://www.w3.org/TR/2008/REC-xml-20081126/.  I also note that the
> Informative Reference to [XMLNS] should be updated to the latest
> edition http://www.w3.org/TR/2009/REC-xml-names-20091208/.

Good catch.

> 9. Section 3.1 says that DSKPP "is layered on a transport mechanism
> such as HTTP" but Section 3.2.2 says that "DSKPP messages ... are
> sent over HTTPS", so a reference to RFC 2616 (probably along with RFC
> 2818) would be appropriate.
> 
> [Doherty, Andrea] Agree; will add reference to RFC2616 and RFC2818
> here.  Note that per Alexey's DISCUSS #9, I will be making the
> RFC2616 reference Normative.  However, as there is not a normative
> mapping to HTTPS, I will be making the reference to RFC2818
> Informative.

Agreed.

> 10. Section 3.2.2 states the following about certificate validation
> or server identity checking:
> 
> In Step 1, the client establishes a TLS connection, and
> authenticates the server (that is, validates the certificate, and
> compares the host name in the URL with the certificate)
> 
> Section 4.2.3 states:
> 
> If K is equivalent to K_SERVER, then the cryptographic module SHOULD
> verify the server's certificate before using it to encrypt R_C in
> accordance with [RFC5280].
> 
> However, no details are provided regarding certificate validation.
> Given that HTTPS is used, a reference to Section 3.1 of RFC 2818 is
> needed.
> 
> [Doherty, Andrea] As per DISCUSS #9, I will be adding an Informative
> Reference to RFC2818 in Section 3.1.  Does this address your concern?
> By "a reference to Section 3.1" did you mean here that a reference to
> Section 3.1 should be added to Sections 3.2.2 and Section 4.2.3?

I think it would be appropriate to reference Section 3.1 of RFC 2818
whether you talk about certificate validation (that would be from
Sections 3.2.2 and 4.2.3 of your document).

> 11. In Section 3.4.3, "the resultant string is hashed using SHA-256
> in accordance with [FIPS180-SHA]"; has any thought been given to hash
> agility?
> 
> [Doherty, Andrea] Yes, esp. as this was raised as a DISCUSS item by
> Russ Housley and Brian Carpenter.  I responded to both Brian and Russ
> to their satisfaction (I also updated the draft to v11; Brian
> confirmed that the change is acceptable, as did Russ through email;
> however, the IESG DISCUSS has not yet been removed).  Here's how the
> topic was addressed in the latest draft:
> 
> * Change Section 1.2, "Versions", to read:
> 
> "There is a provision made in the syntax for an explicit version
> number.  Only version "1.0" is currently specified.
> 
> The purpose for versioning the protocol is to provide a mechanism by
> which changes to required cryptographic algorithms (e.g., SHA-256)
> and attributes (e.g., key size) can be deployed without disrupting
> existing implementations; likewise out-dated implementations can be
> de-commissioned without disrupting operations involving newer
> protocol versions."

Aha, I see that you have addressed algorithm agility via protocol
versioning. That's perhaps a bit heavy-handed (do you really need to rev
the entire protocol whenever you need to upgrade the algorithms used in
the protocol?), but it will work.

> * Add the following to the Security Considerations Section 10.6 on
> "Miscellaneous Considerations"
> 
> "Many protocols need to be algorithm agile.  One reason for this is
> that in the past many protocols had fixed sized fields for
> information such as hash outputs, keys, etc.  This is not the case
> for DSKPP, except for the key size in the computation of DSKPP-PRF.
> Another reason was that protocols did not support algorithm
> negotiation.  This is also not the case for DSKPP, except for the use
> of SHA-256 in the MAC confirmation message.  Updating the key size
> for DSKPP-PRF or the MAC confirmation message algorithm will require
> a new version of the protocol, which is supported with the Version
> attribute."

Yes, that's fine.

> 12. Section 4.2.1 states:
> 
> 3.  The web application processes the request and returns an 
> authentication code to the user, e.g., in the form of an email 
> message
> 
> Is it considered a best practice to send the authentication code via
> email? Nothing is said here about protection of this message (whether
> sent via email or some other method).
> 
> [Doherty, Andrea] We agree that the example in Section 4.2.1 is not
> the best example. I propose to change the text to: 3.  The web
> application processes the request and returns an authentication code
>  to the user, e.g., in response to an enrollment request via a secure
> web session.

That's better.

> 13. Section 10.1 says:
> 
> DSKPP SHOULD, therefore, be run over a transport providing 
> confidentiality and integrity, such as HTTP over Transport Layer 
> Security (TLS) with a suitable ciphersuite, when such threats are a 
> concern.
> 
> Why not MUST?
> 
> [Doherty, Andrea] Will change to MUST.

Thanks.

> 14. Section 10.6.3 says:
> 
> DSKPP servers MUST authenticate themselves...
> 
> Does this mean that a DSKPP client MUST authenticate the server to
> which it connects?
> 
> [Doherty, Andrea] Yes.  Here is how I plan to reword Section 10.6.3.
>  Whenever a successful DSKPP 2-pass protocol run would result in an
> existing K_TOKEN being replaced by a K_TOKEN', the DSKPP client and
> server MUST do the following to prevent a denial-of-service attack
> where an unauthorized DSKPP server replaces a K_TOKEN with another
> key: * The DSKPP server MUST use the AuthenticationDataType extension
> to transmit a second MAC, calculated as described in Section 5.2.2. *
> The DSKPP client MUST authenticate the server using the MAC contained
> in the AuthenticationDataType extension received from the DSKPP
> server to which it is connected.

Good.

> 15. Section 11 states:
> 
> The DSKPP protocol is mostly meant for machine-to-machine 
> communications; as such, most of its elements are tokens not meant 
> for direct human consumption.  If these tokens are presented to the 
> end user, some localization may need to occur.
> 
> Because localization methods are not specified, it is doubtful that
> developers will be able to produce interoperable implementations.
> More details are needed here.
> 
> [Doherty, Andrea] These tokens will not be presented to the users.
> Therefore, I propose to remove the words, "mostly" and "most of", and
> the sentence, "If these tokens are presented to the end user, some
> localization may need to occur."  

If these tokens will not be presented to users, then we don't need to
care about localization. See RFC 2277: "Internationalization is for
humans." Problem solved. :)

> The new paragraph will look like
> this: The DSKPP protocol is meant for machine-to-machine 
> communications; as such, its elements are tokens not meant for direct
> human consumption. DSKPP exchanges information using XML. All XML
> processors are required to understand UTF-8 [RFC3629] and UTF-16
> [RFC2781] encoding, and therefore all DSKPP clients and servers MUST
> understand UTF-8 and UTF-16 encoded XML.  Additionally, DSKPP servers
> and clients MUST NOT encode XML with encodings other than UTF-8 or
> UTF-16.

Do we really need to support both UTF-8 and UTF-16?

> 16. Section 12.3 (MIME Media Type Registration) has the following
> deficiencies:
> 
> - the optional parameter field specifies "charset", but the default
> is "UTF-8", which is not a character set according to RFC 2277.
> 
> [Doherty, Andrea] In his DISCUSS #8, Alexey pointed out that, "I
> believe the last sentence is in violation of MIME, which requires
> US-ASCII to be the default charset value. This is also in violation
> of HTTP, which requires ISO-8859-1." So he suggested removing the
> last quoted sentence.  As such, I plan to remove "Default is UTF-8
> from the optional parameter field.

I'll leave that for Alexey.

> - the encoding considerations field needs to mention that
> implementations need to support both UTF-8 and UTF-16

See above.

> [Doherty, Andrea] I will append the following after "See [RFC3203],
> Section 3.2":  "Implementations need to support both UTF-8 [RFC3629]
> and UTF-16 [RFC2781]."
> 
> - the security considerations field needs to reference this
> specification (especially Section 10), rather than trying to address
> all security issues in just a few words.
> 
> [Doherty, Andrea] Good point.  I'll append the following sentence to
> the security consideration field: "Refer to Section 10 of the
> Published Specification for more details".

+1

> - the interoperability considerations field says "this content type
> provides a basis for a protocol" but that text is not helpful. Are
> there any actual or potential problems with interoperability? If not,
> say "None" here.
> 
> [Doherty, Andrea] I'll replace "this content type provides a basis
> for a protocol" with "None".

+1

> Comment: 1. Section 6 says that "the use of extensions SHOULD be
> carefully considered" but capitalized key words apply to protocols,
> not protocol designers. Suggested text: "protocol designers are
> advised to carefully consider the use of extensions".
> 
> Similar considerations apply to Section 10.4 "Implementers SHOULD
> also be aware that cryptographic algorithms become weaker with
> time."
> 
> [Doherty, Andrea] Will rephrase Section 6 to state, "protocol
> designers are advised to carefully consider the use of extensions",
> and Section 10.4 to state, "Implementers are advised that
> cryptographic algorithms become weaker with time."

OK.

> 2. Section 7.2 "presents a binding of the previous messages to
> HTTP/1.1" but it is not clear if the HTTP binding is
> mandatory-to-implement. This could be added to Section 9.
> 
> [Doherty, Andrea] As stated in Section 3.1, "The principal syntax is
> XML and it is layered on a transport mechanism such as HTTP."  As
> such, it was not envisaged that HTTP would be
> mandatory-to-implement.

OK.

How will we ensure interoperability if no transport mechanism is
mandatory-to-implement?

> 3. Section 1.2 makes provision for versioning, but no guidance is
> provided regarding when the major and minor versions shall be
> incremented, how to compare version numbers, etc. You might be able
> to borrow some text from Section 4.4.1 of RFC 3920 or some similar
> specification.
> 
> [Doherty, Andrea] Good suggestion.  I'll rename Section 1.2 from
> "Versions" to "Version Support" and append the following paragraphs
> after the sentence, "The purpose for versioning the protocol is to
> provide a mechanism by which changes to required cryptographic
> algorithms (e.g., SHA-256) and attributes (e.g., key size) can be
> deployed without disrupting existing implementations; likewise,
> out-dated implementations can be de-commissioned without disrupting
> operations involving newer protocol versions.  The numbering scheme
> for DSKPP versions is "<major>.<minor>".  The major and minor numbers
> MUST be treated as separate integers and each number MAY be
> incremented higher than a single digit.  Thus, "DSKPP 2.4" would be a
> lower version than "DSKPP 2.13", which in turn would be lower than
> "DSKPP 12.3".  Leading zeros (e.g., "DSKPP 6.01") MUST be ignored by
> recipients and MUST NOT be sent.
> 
> The major version number should be incremented only if the message 
> formats or flows have changed so dramatically that an older version
> implementation would not be able to interoperate with a newer
> version.  The minor version number indicates new capabilities, and
> MUST be ignored by an entity with a smaller minor version number, but
> used for informational purposes by the entity with the larger minor
> version number."

Do you envision needing minor version numbers in DSKPP? If not, you
could simplify the text a bit here. Also it might not make sense to have
text about message flows in DSKPP (that might be appropriate for XMPP
but not DSKPP). Perhaps for you something like this is better: "only if
the data formats or security algorithms"...

Thanks for your attention to detail.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



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