[TAXII] TAXII Message IDs

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[TAXII] TAXII Message IDs

Jordan, Bret
In the TAXII Services Specification section 4.1.1 we do not really give any guidance for Message IDs, other than they should not be removed.  I am thinking, based on past experience, and yet to be discovered attacks against TAXII that we should probably say that Message IDs should be 64 bit numbers and should be randomly generated.  We may even go as far as to say they should be a UUID.


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII Message IDs

Jordan, Bret
Would it make sense to have the @message_id and @in_response_to IDs look something like:

message_id="group1.com:status_message-12345678-abcd-efgh-ijkl-123456789012
in_reponse_to=“example.com:discovery_request-abcdefgh-1234-5678-4321-abcdefghijkl"




Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Mar 19, 2015, at 1:05 PM, Jordan, Bret <[hidden email]> wrote:

In the TAXII Services Specification section 4.1.1 we do not really give any guidance for Message IDs, other than they should not be removed.  I am thinking, based on past experience, and yet to be discovered attacks against TAXII that we should probably say that Message IDs should be 64 bit numbers and should be randomly generated.  We may even go as far as to say they should be a UUID.


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 



signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII Message IDs

mdavidson

Bret,

 

I think you meant to say the only guidance is that message IDs should not be reused (instead of removed). This is a good question to raise, and one that I don’t immediately have the answer to.

 

I’ve opened an issue on the TAXII Schemas GitHub tracker [1] so that we can keep track of this thought going forward. If you have something you can share that points to why the current design isn’t as good as it could be, I’m definitely interested in hearing it.

 

Thank you.

-Mark

 

[1] https://github.com/TAXIIProject/TAXII-Specifications/issues/51

 

From: Jordan, Bret [mailto:[hidden email]]
Sent: Thursday, March 19, 2015 4:00 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: Re: [TAXII] TAXII Message IDs

 

Would it make sense to have the @message_id and @in_response_to IDs look something like:

 

message_id="group1.com:status_message-12345678-abcd-efgh-ijkl-123456789012

in_reponse_to=“example.com:discovery_request-abcdefgh-1234-5678-4321-abcdefghijkl"

 

 

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Mar 19, 2015, at 1:05 PM, Jordan, Bret <[hidden email]> wrote:

 

In the TAXII Services Specification section 4.1.1 we do not really give any guidance for Message IDs, other than they should not be removed.  I am thinking, based on past experience, and yet to be discovered attacks against TAXII that we should probably say that Message IDs should be 64 bit numbers and should be randomly generated.  We may even go as far as to say they should be a UUID.

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII Message IDs

Jordan, Bret
I do not have any current attacks against TAXII that would illustrate a problem, however, given past experience with attacking protocols, when you can know or guess the sequence numbers, it is never a good thing.  


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Mar 20, 2015, at 5:17 AM, Davidson II, Mark S <[hidden email]> wrote:

Bret,
 
I think you meant to say the only guidance is that message IDs should not be reused (instead of removed). This is a good question to raise, and one that I don’t immediately have the answer to.
 
I’ve opened an issue on the TAXII Schemas GitHub tracker [1] so that we can keep track of this thought going forward. If you have something you can share that points to why the current design isn’t as good as it could be, I’m definitely interested in hearing it.
 
Thank you.
-Mark
 
 
From: Jordan, Bret [[hidden email]] 
Sent: Thursday, March 19, 2015 4:00 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: Re: [TAXII] TAXII Message IDs
 
Would it make sense to have the @message_id and @in_response_to IDs look something like:
 
message_id="group1.com:status_message-12345678-abcd-efgh-ijkl-123456789012
in_reponse_to=“example.com:discovery_request-abcdefgh-1234-5678-4321-abcdefghijkl"
 
 

 

Thanks,
 
Bret
 
 
 
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 
 
On Mar 19, 2015, at 1:05 PM, Jordan, Bret <[hidden email]> wrote:
 
In the TAXII Services Specification section 4.1.1 we do not really give any guidance for Message IDs, other than they should not be removed.  I am thinking, based on past experience, and yet to be discovered attacks against TAXII that we should probably say that Message IDs should be 64 bit numbers and should be randomly generated.  We may even go as far as to say they should be a UUID.

 

Thanks,
 
Bret
 
 
 
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII Message IDs

Jason Keirstead

FWIW I agree whole-heartedly and IMO this belongs in the spec before we start getting wide adoption.. if it is not part of the spec, people will start crafting implementation with IDs like "1", "2", etc...

There is a public RFC for UUID, no reason it can not be referenced.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Inactive hide details for "Jordan, Bret" ---2015/03/20 11:51:05 AM---I do not have any current attacks against TAXII that would"Jordan, Bret" ---2015/03/20 11:51:05 AM---I do not have any current attacks against TAXII that would illustrate a problem, however, given past

From: "Jordan, Bret" <[hidden email]>
To: <[hidden email]>
Date: 2015/03/20 11:51 AM
Subject: Re: [TAXII] TAXII Message IDs





I do not have any current attacks against TAXII that would illustrate a problem, however, given past experience with attacking protocols, when you can know or guess the sequence numbers, it is never a good thing.  


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
    On Mar 20, 2015, at 5:17 AM, Davidson II, Mark S <[hidden email]> wrote:

    Bret,
     
    I think you meant to say the only guidance is that message IDs should not be reused (instead of removed). This is a good question to raise, and one that I don’t immediately have the answer to.
     
    I’ve opened an issue on the TAXII Schemas GitHub tracker [1] so that we can keep track of this thought going forward. If you have something you can share that points to why the current design isn’t as good as it could be, I’m definitely interested in hearing it.
     
    Thank you.
    -Mark
     
    [1] https://github.com/TAXIIProject/TAXII-Specifications/issues/51
     
      From: Jordan, Bret [[hidden email]]
      Sent:
       Thursday, March 19, 2015 4:00 PM
      To:
       taxii-discussion-list Trusted Automated Exchange of Indicator In
      Subject:
       Re: [TAXII] TAXII Message IDs
       
      Would it make sense to have the @message_id and @in_response_to IDs look something like:
       
      message_id="group1.com:status_message-12345678-abcd-efgh-ijkl-123456789012
      in_reponse_to=“example.com:discovery_request-abcdefgh-1234-5678-4321-abcdefghijkl"
       
       
       
      Thanks,
       
      Bret
       
       
       
      Bret Jordan CISSP
      Director of Security Architecture and Standards | Office of the CTO
      Blue Coat Systems
      PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
      "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
       
        On Mar 19, 2015, at 1:05 PM, Jordan, Bret <[hidden email]> wrote:
         
        In the TAXII Services Specification section 4.1.1 we do not really give any guidance for Message IDs, other than they should not be removed.  I am thinking, based on past experience, and yet to be discovered attacks against TAXII that we should probably say that Message IDs should be 64 bit numbers and should be randomly generated.  We may even go as far as to say they should be a UUID.
         
        Thanks,
         
        Bret
         
         
         
        Bret Jordan CISSP
        Director of Security Architecture and Standards | Office of the CTO
        Blue Coat Systems
        PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
        "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII Message IDs

Dave Cridland
In reply to this post by Jordan, Bret
On 20 March 2015 at 14:49, Jordan, Bret <[hidden email]> wrote:
I do not have any current attacks against TAXII that would illustrate a problem, however, given past experience with attacking protocols, when you can know or guess the sequence numbers, it is never a good thing.  


Interestingly, this is only the case when the ids themselves have semantics associated - you touched on this when you said "sequence numbers" - or when the identifiers themselves are input elsewhere such that they could form a different attack if predictable.

In TAXII, the message identifiers are only used for the message_id and in_response_to fields, as far as I'm aware. These are both signed fields, I believe, so there's some argument that they are input elsewhere. The only attacks I can think of here relate to an attacker using a chosen plaintext attack by selecting an id then used in the in_response_to field of the victim - that's pretty far fetched, but telling people to use unpredictable ids here won't help anyway.

On the other hand, the mission of TAXII traffic *is* under the control of an attacker - I suspect introducing a cryptographic requirement on message identifiers would mean that there was an entropy drain possible; you'll end up either blocking or increasing the predictability of the OS's PRNG then. Neither seems good.

In XMPP, stanzas do not have requirements on identifiers beyond uniqueness, and I'm not aware of any attacks based on this. Stream identifiers *do* have unpredictability requirements, but those are used elsewhere and so an attack would be possible.

Dave.
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII Message IDs

Guido Vranken
In reply to this post by Jordan, Bret
I agree that predictability of identifiers should be avoided if it does not bear a functional advantage over randomized tokens. Aside from any deliberate exploits that may emerge from predictability, there is a chance of accidental mishaps if the spec isn't clearly and unambiguously defined. For example, I have previously addressed the way message ID's were generated in libtaxii, see: https://github.com/TAXIIProject/libtaxii/issues/117 . Here I address the possibility of collisions (because although the generator is based on randomness, the pool of possibilities, 0-10000, is relatively small here).
With respect to collisions, for systems that utilize a sequential generator (1, 2, 3, ..), randomized ID's furthermore 1) remove the complexity of avoiding race conditions and having to implement an atomic generator in multi-threaded systems and 2) avoid overflowing of internal integer variables.

Both for the sake of a smoothly inter-operating constellation of TAXII services as well to avoid confusion on the part of the implementors (personally, as a programmer, I enjoy rigidly defined protocol specifications), I concur with Bret Jordan's suggestion to more strictly define message ID's.

UUID version 4 could be an option here although the RFC on UUID states that v4 isn't completely random ( http://tools.ietf.org/html/rfc4122#section-4.4 -- speaks of time stamps ). Upon first thought that doesn't complicate things significantly from a security perspective, in part because time stamps are featured in TAXII by design (chapter 4.1.4 in the Services Specification) but I'm open to suggestions.

Guido Vranken

Intelworks
www.intelworks.com

On Thu, Mar 19, 2015 at 8:05 PM, Jordan, Bret <[hidden email]> wrote:
In the TAXII Services Specification section 4.1.1 we do not really give any guidance for Message IDs, other than they should not be removed.  I am thinking, based on past experience, and yet to be discovered attacks against TAXII that we should probably say that Message IDs should be 64 bit numbers and should be randomly generated.  We may even go as far as to say they should be a UUID.


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 


Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] TAXII Message IDs

Jordan, Bret
Great ideas and comment Guido.. Those were things I had not yet realized, thanks for brining them to the table.  I think the points you have brought up are sufficient for us to consider some more details to the creation of message IDs. 

When I think of STIX / TAXII long term, I envision massive repos with thousands of servers connecting and sharing data and 10s of millions of clients querying the systems.  I see systems having burst periods of millions of queries per second spread across systems with greater than 32 cores allocated to the system.  Lets make sure what we design can grow.  

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Mar 20, 2015, at 10:38 AM, Guido Vranken <[hidden email]> wrote:

I agree that predictability of identifiers should be avoided if it does not bear a functional advantage over randomized tokens. Aside from any deliberate exploits that may emerge from predictability, there is a chance of accidental mishaps if the spec isn't clearly and unambiguously defined. For example, I have previously addressed the way message ID's were generated in libtaxii, see: https://github.com/TAXIIProject/libtaxii/issues/117 . Here I address the possibility of collisions (because although the generator is based on randomness, the pool of possibilities, 0-10000, is relatively small here).
With respect to collisions, for systems that utilize a sequential generator (1, 2, 3, ..), randomized ID's furthermore 1) remove the complexity of avoiding race conditions and having to implement an atomic generator in multi-threaded systems and 2) avoid overflowing of internal integer variables.

Both for the sake of a smoothly inter-operating constellation of TAXII services as well to avoid confusion on the part of the implementors (personally, as a programmer, I enjoy rigidly defined protocol specifications), I concur with Bret Jordan's suggestion to more strictly define message ID's.

UUID version 4 could be an option here although the RFC on UUID states that v4 isn't completely random ( http://tools.ietf.org/html/rfc4122#section-4.4 -- speaks of time stamps ). Upon first thought that doesn't complicate things significantly from a security perspective, in part because time stamps are featured in TAXII by design (chapter 4.1.4 in the Services Specification) but I'm open to suggestions.

Guido Vranken

Intelworks
www.intelworks.com

On Thu, Mar 19, 2015 at 8:05 PM, Jordan, Bret <[hidden email]> wrote:
In the TAXII Services Specification section 4.1.1 we do not really give any guidance for Message IDs, other than they should not be removed.  I am thinking, based on past experience, and yet to be discovered attacks against TAXII that we should probably say that Message IDs should be 64 bit numbers and should be randomly generated.  We may even go as far as to say they should be a UUID.


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 




signature.asc (858 bytes) Download Attachment