Subject: [KEYPROV] comments on dskpp draft

From: "Salah Machani" <[email-masked]>
Date: Wed, 4 Jul 2007 14:45:21 -0400

Hi Andrea,

I scanned through the DSKPP draft and noticed few things I wanted to
point out - see below.  Overall very good work.

Section 1.2 - last paragraph

-          There is a reference to [4] which I think is not needed here.
This specification also defines mutual key generation between client and
server similar to [4].

Section 1.4 requirements

-          This section does not state whether the protocol should or
should not support some of the use cases that are identified in section
1.3, specifically the following use cases:

o        Use case 1.3.3: provisioning time window 

o        Use case 1.3.5: smart card provisioning and support for smart
card APDUs

o        Use case 1.3.8 - SMS based provisioning

Section 1.4.1: Mandatory requirements:

- General comment:  all requirements are expressed with *SHOULD* instead
of *MUST* while they are classified as mandatory requirements. We may
have to revisit this list. 

- R2: typo: "re-generated"   should be changed to "pre-generated"

- R10:  This might be a requirement for the secret container and not for
the provisioning protocol. 

Sections 3.3.2 and 3.3.3

-          It will be useful to introduce here or somewhere else in the
spec before section 5 the different profiles that are supported.  The
pass-phrase profile is mentioned in section 5.6.5 and is not introduced
anywhere else before.  

Section 3.10.14: the AuthenticationDataType Type

Paragraph b) and last bullet indicate the use of client certificates for
authentication without further details on how they are used while
section 3.4.1.3 suggests using signed data with client certificate for
authentication.   We should clarify this in more details. 

Section 9.2

-          Ref [4] needs to be updated.

-          Ref [7] is incorrect and needs to be updated

Thanks,

Salah Machani

Diversinet Corp., 

[O] +1 (416) 756 2324 x321| [M] +1 (647) 284 7816
|http://www.diversinet.com <http://www.diversinet.com> 

 

Notice to Recipient:  The information in this message is meant only for the intended recipient of the transmission and may contain confidential or privileged information. 
Any copying, retransmittal, taking of action in reliance on, or other use of the information in this communication by persons other than the addressees is prohibited.  
If you received this email in error, please immediately notify us and please delete or destroy all copies of this message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors.  Thank you.

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

---

From: "Doherty, Andrea" <[email-masked]>
Date: Wed, 4 Jul 2007 15:32:46 -0400

Salah,
Please see responses below.
Andrea

________________________________

From: Salah Machani [mailto:[email-masked]] 
Sent: Wednesday, July 04, 2007 2:45 PM
To: Doherty, Andrea; [email-masked]
Subject: comments on dskpp draft

Hi Andrea,

I scanned through the DSKPP draft and noticed few things I wanted to
point out - see below.  Overall very good work.
[Doherty, Andrea] Thanks. 

-          There is a reference to [4] which I think is not needed here.
This specification also defines mutual key generation between client and
server similar to [4].
[Doherty, Andrea] Yes, I agree.  

      Somewhere mention of RFC4758 may be required, if even to state
that this spec obsoletes that one.  Not sure how to do that...   Perhaps
it is not actually handled in this document but only if this draft made
it to RFC status (?)

Section 1.4 requirements

o        Use case 1.3.3: provisioning time window 
[Doherty, Andrea] This use case is more of a desirable requirement, and
is not explicitly covered by the protocol at this time.  Would you
agree? 

o        Use case 1.3.5: smart card provisioning and support for smart
card APDUs
[Doherty, Andrea] The requirement here pertains to the last paragraph of
this section, and is already covered by R11. 

o        Use case 1.3.8 - SMS based provisioning
[Doherty, Andrea] Issue#7 in the Issue Tracker covers this, and I did
not address it in the recent draft, as it seemed to be out-of-scope
until we resolve whether it is desired or not.  How about if for now we
add this as a Desirable Requirement?

- General comment:  all requirements are expressed with *SHOULD* instead
of *MUST* while they are classified as mandatory requirements. We may
have to revisit this list. 
[Doherty, Andrea] Agree.  For now I'll change to "must". 

- R2: typo: "re-generated"   should be changed to "pre-generated"
[Doherty, Andrea] Good catch. 

- R10:  This might be a requirement for the secret container and not for
the provisioning protocol. 
[Doherty, Andrea] Agree if the PSKC is the only option, which it is not.
That said, since PSKC is the default container, and since container
details are out of the scope of the protocol, I think this requirement
should be removed. 

Sections 3.3.2 and 3.3.3

-          It will be useful to introduce here or somewhere else in the
spec before section 5 the different profiles that are supported.  The
pass-phrase profile is mentioned in section 5.6.5 and is not introduced
anywhere else before.  
[Doherty, Andrea] You're right.  They are covered in the appendix, but
should be mentioned before section 5. 

Section 9.2

-          Ref [4] needs to be updated.
[Doherty, Andrea] Will update as per comment (above) on Section 1.2. 

-          Ref [7] is incorrect and needs to be updated
[Doherty, Andrea] Will update. 

Thanks,

Salah Machani

Diversinet Corp., 

 

________________________________

Notice to Recipient: The information in this message is meant only for
the intended recipient of the transmission and may contain confidential
or privileged information. 
Any copying, retransmittal, taking of action in reliance on, or other
use of the information in this communication by persons other than the
addressees is prohibited. 
If you received this email in error, please immediately notify us and
please delete or destroy all copies of this message.
This message may have been altered without your or our knowledge and the
sender does not accept any liability for any errors. Thank you.