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

Re: [pkix] TAMP spec



Title: 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:stefan at aaa-sec.com]
Sent: Wednesday, November 11, 2009 6:39 AM
To: Carl Wallace; denis.pinkas at bull.net; 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" <CWallace at cygnacom.com> 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: pkix-bounces at ietf.org [mailto:pkix-bounces at ietf.org] 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:pkix-bounces at ietf.org>

À : pkix <mailto%20:pkix at ietf.org>  

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
pkix at ietf.org <mailto:%20pkix at ietf.org>
https://www.ietf.org/mailman/listinfo/pkix

 


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


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.