Re: [pkix] TAMP spec

["Carl Wallace" <[e-mail]>]

Inline...

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Denis Pinkas
Sent: Monday, November 16, 2009 4:23 AM
To: pkix
Subject: Re: [pkix] TAMP spec

 

I will summarize in this email my comments on the draft.

 

I have finally been able to review the changes that were made to version 04. 
Some parts of the revised text are not crystal clear to me.

 

I am still wondering whether the draft complies with draft-ietf-pkix-ta-mgmt-reqs-04. 

On page 11, we have:

3.5.  RFC 5280 Support

3.5.1.  Functional Requirements

   A trust anchor management protocol MUST enable management of trust

   anchors that will be used to validate certification paths and CRLs in

   accordance with [RFC5280] and [RFC5055].  A trust anchor format MUST

   enable the representation of constraints that influence certification

   path validation or otherwise establish the scope of usage of the

   trust anchor public key.  Examples of such constraints are name

   constraints, certificate policies, and key usage.

The problem is that the current format does not allow a RP or a TAS manager to add constraints 
to a self-signed certificate. This limitation should be mentioned in the TAMP draft 
(or the TAMP draft should be changed).

 

Since it seems that no change will be made to the draft, I believe this limitation should be indicated.

[CW] Obviously this can also be done when the self-signed certificate is created.  As Geoff noted, this can also be done with a wrapper.  It's not clear to me why we'd want to include things in the TA that have no processing semantics but it's certainly possible as it is with RFC 5280.

 

I have provided some text below to address this concern.

 

=====================================================================

 

Stefan said:

 

I think the following text is confusing to a new reader:

"Some sequence number generation schemes, e.g., time-based, 
do not require maintenance of state information."

This is a general design consideration for designing the protocol but 
has nothing to do with security considerations related to deployment of the specified protocol.

This text seems relevant only if you provide any security related rationales why such approach 
was not selected. Else, I would simply remove this text and possibly add a corresponding text 
in some other place of the document discussing design considerations.

[CW] This is approach was not "not selected".  It's a method the fits the usage described in the draft.

 

In fact, using time-based sequence numbers allow to solve some issues in case 
more than one trust anchor store manager manages a given trust anchor store. 
I have provided some text at the end of this email to address the problem. 
Since parallel management is not mandated, the discussion can be in the security 
considerations section, since it really relates to security (denial of service in this case).

[CW] As previously discussed, there are no synchronization issues between multiple TA store managers.  There is no denial of service unless you have access to my key. My sequence number has no bearing on messages you generate and vice versa.  

 

1. On page 21, the text says :

   "TrustAnchorInfo is intended to serve as a
   minimalist representation of trust anchor information for scenarios
   where storage or bandwidth is highly constrained".

Russ, said: "I agree that the representation is not minimal.  
That description should be removed". 


I suggest : 

"TrustAnchorInfo does not use a structure derived from RFC 5280. 
Since it does not include a validity field, the validity period 
of the trust anchor information is unspecified.  The structure 
optionally includes a TrustAnchorTitle with a UTF8String syntax 
and which plays a role similar to the issuer field from a certificate 
with a DN syntax.  It may include a specific element called certPath 
to control certificate path validation". 
[CW] I do not agree with Russ that this is not a minimal representation.  I agree it need not be minimal since it can contain various information.  In any case, I prefer the existing text, which is historically accurate - the structure was in fact designed to enable expression representations as minimal as key and name.

2. Then the text says on the same page:

   "Implementations are not required to support all three options.  The
   unsupportedTrustAnchorFormat error code should be indicated when
   generating a TAMPError due to receipt of an unsupported trust anchor
   format".

At this place, the characteristics of use of these three structures 
should be indicated since they are not identical. 

[CW] The differences between these structures are discussed in TAF.

 

I propose to add the following text:

"The functionalities supported by each option are not the same. 
Usually self-signed certificates (supported through the certificate field) 
can be used for several purposes and it is up to relying parties 
to decide for which purpose(s) they should be used. However, when 
the certificate choice is being used, the TrustAnchorChoice structure 
does not allow a trust anchor store manager specifying constraints 
nor the purpose (or scope) for which a self-signed certificate may be used.

 

On the contrary, the two other structures are able to support 
additional constraints which may be defined by trust anchor store managers.
When they are used without additional specific extensions, 
the purposes for which the trust anchor info may be used to verify 
certification paths needs to be locally defined; this means that different 
usages for different trust anchors placed in the same trust anchor 
store are not possible either. One way to have different usages for different 
trust anchors without using specific extensions is to use a different trust 
anchor store for every different usage. 

[CW] There is text in TAF that highlights the fact that no additional constraints can be associate with the certificate option but can be with TBSCert and TAI.

Note that the Extended Key Usage extension, as defined in RFC 5280 
indicates one or more purposes for which the trust anchor itself may be used.

Thus, it cannot be used to indicate for which purpose certificates 
from paths terminating to that trust anchor may be used".
[CW] I don't see any reason note this in TAMP.  It's more would be a good fit for an EKU constraints draft, were one to be written.

3. On page 22, there is the following text:

   The TAMP Status Query message MUST be signed.  For the query message
   to be valid, the trust anchor store MUST be an intended recipient of
   the query, the sequence number checking described in Section 6 MUST
   be successful when the TAMP message signer is a trust anchor,

What does the end of the sentence mean ? A signer is not a trust anchor. 
Please clarify and rephrase.
[CW] See section 6 for a clarification.  As you observe below, sequence number processing is not required when a TAMP message is validated using a certificate instead of a trust anchor.

4. On page 33, the text says :

« The TrustAnchorChangeInfo structure or the TBSCertificateChangeInfo 
structure is used to provide the revised configuration of the management 
or identity trust anchor".

The end of the sentence is unclear "management or identity trust anchor" ?
[CW] These terms are defined earlier in the draft.  The point here is that apex TAs cannot be changed with this structure.

 


Change proposal:

"The TrustAnchorChangeInfo structure or the TBSCertificateChangeInfo structure 
is used to provide the revised configuration of the tbsCert and the taInfo 
structures respectively. As a consequence, the trust anchor store must make 
a difference between the three options every time one of the structures 
is stored or changed".


5. On page 55, the text says:

                       "This balance is achieved by performing sequence
   number checking on TAMP messages that are validated directly using a
   trust anchor, and allowing these checks to be skipped whenever the
   TAMP message originator is not represented by a trust anchor".

What does the end of the sentence mean? What is the difference between 
a "TAMP message originator" that is represented by a trust anchor and 
one which is not? TAMP message originators are trust anchor store managers 
that use a signing key to access the trust anchor store.  

Some explanations may be found, but only on the next page:

   "This could be the apex trust anchor
   operational public key or a management trust anchor public key.  In
   the first case, the apex trust anchor operational public key is used
   directly to validate the TAMP message digital signature.  In the
   second case, a management trust anchor public key is used directly to
   validate the TAMP message digital signature".

These explanations should be moved. However, I still have a problem 
to understand how a management trust anchor public key is defined.

A final question remains: why can checks be skipped "whenever 
the TAMP message originator is not represented by a trust anchor" ?
[CW] See the first paragraph of section 6.  The primary reason is that it's easier to know when to delete sequence number values for TAs, since they are resident in the store.  It's harder for certificate holders since expiration or deletion may occur independent of the store.

6. Then the text states on the same page:

   "Implementations MUST perform sequence number checking on TAMP
   messages that are validated directly using a trust anchor" 

but then the text states:

"and MAY perform sequence number checking for TAMP messages validated 
using a certification path".

Why is there a difference between the two cases? Please explain and revise.

[CW] See above.  



7. On page 64, at the end of the security considerations section, 
I propose to add the following text:

"In the event of loss sequence number values by one trust anchor store manager, 
sequence number state can be restored by inspecting the most recently 
generated TAMP messages, if these messages are logged.

[CW] OK.  I will add "if these messages are logged" to the previous proposed text.


As sequence number values are used to detect replay attempts, there are difficulties 
to use concurrently several trust anchor store managers unless a strong and 
continuous synchronization between them is being maintained at all times.

[CW] As noted in previous messages, this is not true.  The only case where this would be true is where the two TA managers are sharing a private key and there is no need to support this scenario.


When only one trust anchor store manager is being active at a time and in case 
of a failure, a backup trust anchor store manager must use sequence numbers 
that are greater than the last ones being used. One way to avoid a continuous 
communication of the last sequence number values being used between different 
trust anchor store managers is to use sequence numbers built using a date and 
time value in the higher bits of the sequence number values and a random number 
in the lower bits. If reasonable time synchronization is maintained between 
the trust anchor store managers, after a few seconds, the backup trust anchor 
store manager should normally be able to successfully access the trust anchor 
stores initially managed by the master trust anchor store manager".
[CW] No synchronization is required if they use different private keys.  

 


Denis


============================================================================

 

De : Carl Wallace 

	À : Stefan Santesson,denis.pinkas,pkix 

	Date : 2009-11-10, 22:54:41

	Sujet : RE: [pkix] TAMP spec

	 

	I agree this is an unanticipated statement for the security considerations section and will strike that sentence, which leaves the following as the draft text:

	 

	As sequence number values are used to detect replay attempts, trust anchor store managers must take care to maintain their own sequence number state, i.e., knowledge of which sequence number to include in the next TAMP message generated by the trust anchor store manager.  Loss of sequence number state can result in generation of TAMP messages that cannot be processed due to seqNumFailure.  In the event of loss, sequence number state can be restored by inspecting the most recently generated TAMP message or in collaboration with a trust anchor store manager who can successfully issue a TAMPStatusQuery message. 

	 

	From: Stefan Santesson [mailto:[e-mail]] 
	Sent: Wednesday, November 11, 2009 6:39 AM
	To: Carl Wallace; [e-mail]; pkix
	Subject: Re: [pkix] TAMP spec

	 

	Carl,
	
	I think the following text is confusing to a new reader:
	
	"Some sequence number generation schemes, e.g., time-based, do not require maintenance of state information."
	
	This is a general design consideration for designing the protocol but has nothing to do with security considerations related to deployment of the specified protocol.
	
	This text seems relevant only if you provide any security related rationales why such approach was not selected.
	Else, I would simply remove this text and possibly add a corresponding text in some other place of the document discussing design considerations.
	
	/Stefan
	
	
	
	On 09-11-11 3:23 AM, "Carl Wallace" <[e-mail]> wrote:

	Some draft text for security considerations is below.  I don't think we need text on the possible future extensions.  Once we agree on the text below, I'll submit a new draft.
	 
	As sequence number values are used to detect replay attempts, trust anchor store managers must take care to maintain their own sequence number state, i.e., knowledge of which sequence number to include in the next TAMP message generated by the trust anchor store manager.  Loss of sequence number state can result in generation of TAMP messages that cannot be processed due to seqNumFailure.  In the event of loss, sequence number state can be restored by inspecting the most recently generated TAMP message or in collaboration with a trust anchor store manager who can successfully issue a TAMPStatusQuery message.  Some sequence number generation schemes, e.g., time-based, do not require maintenance of state information.
	 
	
	From: [e-mail] [mailto:[e-mail]] On Behalf Of Denis Pinkas
	Sent: Tuesday, November 10, 2009 7:49 PM
	To: pkix
	Subject: Re: [pkix] TAMP spec
	
	
	Steve,
	
	
	
	I still see need for additional changes to be made to the document.
	
	
	
	In particular, Carl said on october 29:
	
	"I will add some text to the security considerations section describing the consequences of losing sequence number state".
	
	The text to cover this point is not present in version 4.
	
	
	
	I also believe that text to cover the missing functionnalities and possible future evolutions should be added.
	
	If there is an agreement on the principle of such an addition, I can propose such a text.
	
	
	
	Denis

	
	----- Message reçu ----- 
	
	De : pkix-bounces <mailto%20:[e-mail]> 
	
	À : pkix <mailto%20:[e-mail]>  
	
	Date : 2009-11-10, 07:56:51
	
	Sujet : [pkix] TAMP spec
	
	
	
	Folks,
	
	The TAMP WGLC period ended on 10/19. While there have been useful 
	discussions beyond that time, it now seems appropriate to consider 
	this WGLC to be over.
	
	Based on the messages from Denis, Carl, Russ, and Santosh over the 
	period from 10/8-11/3, I see no need for additional changes need to 
	be made to this document. Additional features and options may be 
	pursed in a future, extensions document.
	
	Steve
	_______________________________________________
	pkix mailing list
	[e-mail] <mailto:[e-mail]> 
	https://www.ietf.org/mailman/listinfo/pkix

	 

	
________________________________


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