OASIS Key Management Interoperability Protocol (KMIP) TC

Documents reviewed: kmip-rng-base-wd01 kmip-rng-query-wd01 kmip-rng-attribute-wd01 kmip-rng-specify-wd01 Comment on kmip-rng-base-wd01: Draft NIST SP800-90C specifies two constructions for NRBGs: XOR and oversampling. Can we add an NRBG construction field enumeration to the RNG Parameters structure to identify these construction types? General comments on RNG support and usage in KMIP: Whilst I think that each of these proposals has merit, and are beginning to partially address some of the issues that I have raised before, I do not believe that they go far enough. They do not address the most serious issue: the proposed cryptographic services for the 1.2 standard support implementations that allow any client to seed an RNG used by the server, and all other clients. The standard does not encourage, recommend, or require secure random implementations. At the very least, Usage Guide documentation should identify this issue, and discourage implementations that allow these RNG side channel attacks. As a next step, there should be a separate profile for each random reseed behaviour that a server can implement. Best of all, require independent random instances that do not leak information between clients, or clients and server. John ---------------------------------------------------------------------- John Leiseboer QuintessenceLabs Pty Ltd Chief Technology Officer Suite 23, Physics Building #38 Phone: +61 7 5494 9291 (Qld) Science Road Phone: +61 2 6125 9498 (ACT) Australian National University Mobile: +61 409 487 510 Acton ACT 0200 Fax: +61 2 6125 7180 AUSTRALIA Email: JL@quintessencelabs.com www.quintessencelabs.com ----------------------------------------------------------------------

I have reviewed the RNG / PRNG proposals and have the following comments and questions. kmip-rng-base-wd01: RNG Parameters: Some of the parts of RNG Parameters are optional, depending on the algorithm. We should specify which parts are expected for which algorithm. Cryptographic Length: This needs to be defined. What is it for which algorithm? Is it the perceived security strength? That is, for HMAC DRBG 128 bit security strength, should this be 128? For EC DRBG using a P256 curve should this be 128 or 256? DRBG Algorithm: We need to specify exactly which algorithms these are. I assume they are meant to be NIST's SP800-90 algorithms? If so, we should we be explicit. DRBG Algorithms and RNG Algorithm Enumeration: I think it makes sense to combine these two enumerations and for us to have a single list of algorithms. Recommended Curve: This should be Curve, indicating it is the curve which must be or has been used. A common PRNG parameter which is not able to be specified in the current proposal is Prediction Resistance. This is the combining of one bit of entropy with each output bit. This can be on or off. This is discussed in detail in NIST's SP800-90a-rev1. It would be good to be able to indicate what entropy sources have been or will be used to seed a PRNG algorithm. Is it fair to assume that all PRNG instances in a server will be seeded with the same types of entropy sources, and as such could this be the same for all PRNG algorithms? kmip-rng-query-wd01 If a server implementation supports the specification then it should be able to report which algorithms and parameter options it supports. As such, I don't think "unspecified" makes sense. Peter ------------------------------------------------ Peter Robinson - peter.robinson@rsa.com Senior Engineering Manager RSA, The Security Division of EMC - http://www.rsa.com/ Level 11, Central Plaza One, 345 Queen Street, Brisbane, Queensland 4000, AUSTRALIA. Phone: +61 7 3032 5253, Mobile: +61 407 962 150.

As discussed in the call last week, attached is a draft statement of use which we plan to make once we complete the public review and vote to committee specification level and then have the correct URLs to include. The SoU as previously agreed will be based on the completed July 2013 interop testing and we expect that other vendors who participated in that round of testing will also make corresponding statements of use covering the level of functionality tested. As noted there are two vendors who are not KMIP members who may elect to make a SoU (via the kmip-comment mailing list). Each SoU must be approved by TC resolution as an acceptable SoU with respect to the committee specification. Thanks, Tim. Attachment: KMIP-SOU-Cryptsoft-12-Dec-2013-draft.doc Description: MS-Word document

> DRBG Algorithms and RNG Algorithm Enumeration: I think it makes sense to combine these two enumerations and for us to have a single list of algorithms. Okay with me so long as draft NIST SP-800-90C NRBG constructions consisting of (NRBG + construction type + DRBG) are supported. John -----Original Message----- From: kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ] On Behalf Of Robinson, Peter (RSA Engineering) Sent: Thursday, 12 December 2013 12:59 PM To: kmip@lists.oasis-open.org Cc: Carielli, Sandra; Pingel, Stefan; Brown, Jaimee; Furlong, Judith; Griffin, Robert Subject: [kmip] KMIP: RNG Proposals I have reviewed the RNG / PRNG proposals and have the following comments and questions. kmip-rng-base-wd01: RNG Parameters: Some of the parts of RNG Parameters are optional, depending on the algorithm. We should specify which parts are expected for which algorithm. Cryptographic Length: This needs to be defined. What is it for which algorithm? Is it the perceived security strength? That is, for HMAC DRBG 128 bit security strength, should this be 128? For EC DRBG using a P256 curve should this be 128 or 256? DRBG Algorithm: We need to specify exactly which algorithms these are. I assume they are meant to be NIST's SP800-90 algorithms? If so, we should we be explicit. DRBG Algorithms and RNG Algorithm Enumeration: I think it makes sense to combine these two enumerations and for us to have a single list of algorithms. Recommended Curve: This should be Curve, indicating it is the curve which must be or has been used. A common PRNG parameter which is not able to be specified in the current proposal is Prediction Resistance. This is the combining of one bit of entropy with each output bit. This can be on or off. This is discussed in detail in NIST's SP800-90a-rev1. It would be good to be able to indicate what entropy sources have been or will be used to seed a PRNG algorithm. Is it fair to assume that all PRNG instances in a server will be seeded with the same types of entropy sources, and as such could this be the same for all PRNG algorithms? kmip-rng-query-wd01 If a server implementation supports the specification then it should be able to report which algorithms and parameter options it supports. As such, I don't think "unspecified" makes sense. Peter ------------------------------------------------ Peter Robinson - peter.robinson@rsa.com Senior Engineering Manager RSA, The Security Division of EMC - http://www.rsa.com/ Level 11, Central Plaza One, 345 Queen Street, Brisbane, Queensland 4000, AUSTRALIA. Phone: +61 7 3032 5253, Mobile: +61 407 962 150. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Thanks for the feedback Peter - and clearly the background from how we came to this approach isn't clear to those who weren't involved so more details need to be added. It is good to get that feedback. Responses on the specific items are inline. On 12/12/2013 12:59 PM, Robinson, Peter (RSA Engineering) wrote: > I have reviewed the RNG / PRNG proposals and have the following comments and questions. > > kmip-rng-base-wd01: > > RNG Parameters: Some of the parts of RNG Parameters are optional, depending on the algorithm. We should specify which parts are expected for which algorithm. The parameters are optional as the implementation may or may not know or want to provide that level of detail. It allows for as much information as is used in FIPS140 validation to be able to be provided but does not preclude less information. It also allows for providing details as to the cryptographic building blocks in RNGs independent of the particular - allowing a client to be able to see if there is something that it wants to be able to make a decision on acceptability based on that information. There isn't a fixed list and they are also optional for that reason. If you want to see examples of common usage then the RNG validation list is the right starting point. > Cryptographic Length: This needs to be defined. What is it for which algorithm? Is it the perceived security strength? That is, for HMAC DRBG 128 bit security strength, should this be 128? For EC DRBG using a P256 curve should this be 128 or 256? Cryptographic Length is a well defined attribute. And in this context is the the length of the corresponding Cryptographic Algorithm that is being used as a building block. It is not the perceived security strength - that would be a separate attribute to add - and one which when discussed as a group lead to it not being included. > DRBG Algorithm: We need to specify exactly which algorithms these are. I assume they are meant to be NIST's SP800-90 algorithms? If so, we should we be explicit. They are explicitly listed. See the 9.1.3.2.38 DRBG Algorithm Enumeration. It lists them there. > DRBG Algorithms and RNG Algorithm Enumeration: I think it makes sense to combine these two enumerations and for us to have a single list of algorithms. It doesn't make sense to combine them at all as there are groups of classifications and specific algorithms within each group. This approach was discussed and modelled of the most detailed specification of RNGs available - that from NIST and the FIPS140 cryptographic module validation program and worked through with the NIST representative at the time. You should take a look back through the RNG validation lists and look at the history of how NIST has approached their descriptive terminology in this area (and they continue to expand on it). > Recommended Curve: This should be Curve, indicating it is the curve which must be or has been used. No it shouldn't. This refers to the existing concept within KMIP which has always been called "Recommended Curve". That just happens to be the approach that KMIP uses which you can debate whether or not that was a good name to have picked back in KMIP 1.0 - but it is the name - and the existing concept. All references to curves use this attribute. > A common PRNG parameter which is not able to be specified in the current proposal is Prediction Resistance. This is the combining of one bit of entropy with each output bit. This can be on or off. This is discussed in detail in NIST's SP800-90a-rev1. We haven't seen any NIST indication as yet that this will be included in the RNG testing. It can be added if this is of interest and you see a use case for it. > It would be good to be able to indicate what entropy sources have been or will be used to seed a PRNG algorithm. Is it fair to assume that all PRNG instances in a server will be seeded with the same types of entropy sources, and as such could this be the same for all PRNG algorithms? That is an interesting area for discussion - classification of the actual entropy source - and something I think is a lot broader as an area. To date no one has indicate that this is something which is of interest - and NIST itself don't have a taxonomy for classification of actual entropy sources. The assumption you ask about isn't one that is valid to make from my understanding. It would be useful to get comments from others. I think this whole area (entropy sources) is one the group hasn't indicated an interest or a use case for tackling as yet. Thanks, Tim.

Tim, Good points -- just a couple of follow up comments below. Bob > > A common PRNG parameter which is not able to be specified in the current > proposal is Prediction Resistance. This is the combining of one bit of entropy > with each output bit. This can be on or off. This is discussed in detail in NIST's > SP800-90a-rev1. > We haven't seen any NIST indication as yet that this will be included in the > RNG testing. It can be added if this is of interest and you see a use case for it. [<[Bob]>] I think that Peter is referring to the fact that NIST specify each DRBG as being instantiated with Prediction Resistance on, or off -- both/either of which can be tested. So I think if we are going to have attributes which represent the state in which the PRNG was used, then perhaps just an attribute flag indicating whether or not 'Prediction Resistance' was enabled should be sufficient. For an example, here's a link to a NIST algorithm validation with PR enabled: http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html#188 > > > It would be good to be able to indicate what entropy sources have been or > will be used to seed a PRNG algorithm. Is it fair to assume that all PRNG > instances in a server will be seeded with the same types of entropy sources, > and as such could this be the same for all PRNG algorithms? > > That is an interesting area for discussion - classification of the actual entropy > source - and something I think is a lot broader as an area. To date no one has > indicate that this is something which is of interest - and NIST itself don't have > a taxonomy for classification of actual entropy sources. The assumption you > ask about isn't one that is valid to make from my understanding. It would be > useful to get comments from others. I think this whole area (entropy > sources) is one the group hasn't indicated an interest or a use case for > tackling as yet. [<[Bob]>] Definitely an interesting topic and one which NIST has yet to finalize, although they have indicated in recent drafts of SP800-90B that they will be qualifying the seed sources -- what that will look like is hard to guess, but my feeling is that they will be going with the 'min-entropy' number as a qualifier for h/w sources. Regardless, my recommendation is that we be prepared to support some sort of qualification of the seeding source, which could be another DRBG, or most likely a h/w source. Perhaps providing a 'seed qualification' field which supports both DRBGs and future h/w qualifications of min-entropy?

On 13/12/2013 9:18 AM, Burns, Robert wrote: > [<[Bob]>] I think that Peter is referring to the fact that NIST > specify each DRBG as being instantiated with Prediction Resistance on, > or off -- both/either of which can be tested. So I think if we are > going to have attributes which represent the state in which the PRNG > was used, then perhaps just an attribute flag indicating whether or > not 'Prediction Resistance' was enabled should be sufficient. If the objective is to list all the possible testing options covered in the validation suites then that certainly can be done but there is a lot more than just prediction resistance which isn't currently modelled. At the time the clear focus was to have enough information to make decisions in the client and to indicate the building blocks being used. For those who are not familiar with the area and want to read up on it you should read through the following two NIST documents to get a clearer idea as to the scope that would need to be addressed if we as a group want to expand to cover that area in addition to what is currently noted. http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf http://csrc.nist.gov/groups/STM/cavp/documents/drbg/DRBGVS.pdf We went through that material before the original proposal was created and it is an area I'm rather familiar with having taken multiple modules through FIPS140-2 validation across multiple organisations. Listing all the testing options will add another 6-12 fields within the RNG Parameters structure. On the entropy source approach, I too think that waiting and seeing where NIST are going on that topic prior to tackling it is the sensible approach, noting that we previously backed away from tackling that area and settled on using the high-level elements from the NIST RNG concepts as the base. The number of times NIST has proposed and the changed the approach of how to handling entropy sources and how they are currently handled within the FIPS140-2 context shouldn't be ignored in my view. Again this all can be revisited if there is general interest in a broader scope - but given previously we discussed this for KMIP 1.2 and then backed it out of the proposals I'm cautious to repeat that same process when ultimately it came down to insufficient member support to commit to implementations that would actually exercise that sort of functionality and a general consensus that tackling items in an incremental fashion was the right approach to take. It would be good to get the views from vendors who have taken modules through validation (and from others) as to whether or not expanding the scope to covering all the options within the validation suites is of interest. If there is a general consensus then I can certainly update the base proposal to include additional fields. Thanks, Tim.

Tim,   I was merely responding to your comment on Peter's recommendation to support prediction resistance, which was: " We haven't seen any NIST indication as yet that this will be included in the RNG testing. It can be added if this is of interest and you see a use case for it. ".   I found your assertion about NIST not including it in the RNG testing curious, (to say the least), so I thought I'd chip in and try to clarify.  Obviously, my response missed the mark.   Regarding your second sentence in your response above, I would like to indicate that * if * we are adding attributes at this time, then it is indeed of interest to me – the mere fact that NIST actually includes this attribute on the algorithm validation certificate is reason enough to make the attribute available, IMHO.  I am * not * advocating adding every testing attribute or making any other changes; just stating that I do see the value in the ‘prediction resistance’ attribute on a NIST SP800-90(A) DRBG object.   Bob   > -----Original Message----- > From: Tim Hudson [mailto:tjh@cryptsoft.com] > Sent: Thursday, December 12, 2013 6:58 PM > To: Burns, Robert > Cc: Robinson, Peter (RSA Engineering); kmip@lists.oasis-open.org; Carielli, > Sandra; Pingel, Stefan; Brown, Jaimee; Furlong, Judith; Griffin, Robert > Subject: Re: [kmip] KMIP: RNG Proposals > > On 13/12/2013 9:18 AM, Burns, Robert wrote: > > [<[Bob]>] I think that Peter is referring to the fact that NIST > > specify each DRBG as being instantiated with Prediction Resistance on, > > or off -- both/either of which can be tested. So I think if we are > > going to have attributes which represent the state in which the PRNG > > was used, then perhaps just an attribute flag indicating whether or > > not 'Prediction Resistance' was enabled should be sufficient. > > If the objective is to list all the possible testing options covered in the > validation suites then that certainly can be done but there is a lot more than > just prediction resistance which isn't currently modelled. At the time the > clear focus was to have enough information to make decisions in the client > and to indicate the building blocks being used. > > For those who are not familiar with the area and want to read up on it you > should read through the following two NIST documents to get a clearer idea > as to the scope that would need to be addressed if we as a group want to > expand to cover that area in addition to what is currently noted. > > http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf > http://csrc.nist.gov/groups/STM/cavp/documents/drbg/DRBGVS.pdf > > We went through that material before the original proposal was created and > it is an area I'm rather familiar with having taken multiple modules through > FIPS140-2 validation across multiple organisations. Listing all the testing > options will add another 6-12 fields within the RNG Parameters structure. > > On the entropy source approach, I too think that waiting and seeing where > NIST are going on that topic prior to tackling it is the sensible approach, noting > that we previously backed away from tackling that area and settled on using > the high-level elements from the NIST RNG concepts as the base. The > number of times NIST has proposed and the changed the approach of how to > handling entropy sources and how they are currently handled within the > FIPS140-2 context shouldn't be ignored in my view. > > Again this all can be revisited if there is general interest in a broader scope - > but given previously we discussed this for KMIP 1.2 and then backed it out of > the proposals I'm cautious to repeat that same process when ultimately it > came down to insufficient member support to commit to implementations > that would actually exercise that sort of functionality and a general > consensus that tackling items in an incremental fashion was the right > approach to take. > > It would be good to get the views from vendors who have taken modules > through validation (and from others) as to whether or not expanding the > scope to covering all the options within the validation suites is of interest. If > there is a general consensus then I can certainly update the base proposal to > include additional fields. > > Thanks, > Tim. >  

On 14/12/2013 4:30 AM, Burns, Robert wrote: Tim,   I was merely responding to your comment on Peter's recommendation to support prediction resistance, which was: We haven't seen any NIST indication as yet that this will be included in the RNG testing. It can be added if this is of interest and you see a use case for it. . Thanks for noting that - I hadn't realised that NIST had retrofitted the prediction resistance testing statements into the DRBG validation lists (and seeing that an RSA product was the first put through that testing it fills in the gap as to why Peter suggested it). It wasn't in the lists at the time we worked through the original proposal but I can see now that NIST went back and updated the previous entries in what appears to be late 2012 - so my statement was indeed incorrect. NIST include DRBG testing for prediction resistance on or off in the DBRGVS. If we are going to include that sort of information then whether or not reseeding is supported and whether or not a derivation function is included are also equally relevant I would think. Thoughts? Tim.

Following up on the suggestion from Bob Burns that if NIST lists it in the validation list that is a good indication we should include it, I've taken another pass through the current list to pick up what we missed last time around and any other changes and to check to see what else I might have missed. For the current NIST RNG validation lists there are the following items not covered in the current working draft:     (None)     For the current NIST RNGVS there are the following testing items not covered in the current working draft:     Minimum and maximum seed lengths (bit ranges)     Q value (if a specific value is required) For the current NIST DRBG validation lists there are the following items not covered in the current working draft:     Prediction Resistance Tested: Enabled     Prediction Resistance Tested: Not Enabled     BlockCipher_No_df     BlockCipher_Use_df (df = whether or not a derivation function is used) For the current NIST DRBGVS there are the following testing items not covered in the current working draft:     Entropy Input (bit length ranges)     Nonce (bit length ranges)     Personalization string (bit length ranges)     Additional input (bit length ranges) And for the operational testing parameters:     Requested Instantiation Security Strength     Requested Security Strength     Reseeding supported See http://csrc.nist.gov/groups/STM/cavp/documents/rng/rngval.html and http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html If we added the following into RNG Parameters that would cover off on what is currently noted in the validation lists:     Prediction Resistance Enabled - Boolean     Derivation Function Used - Boolean If we want to include any of the other items that are used in the testing process then that is a larger set of changes and those are items not reflected in the validation lists. Tim.

If we added the following into RNG Parameters that would cover off on what is currently noted in the validation lists: Prediction Resistance Enabled - Boolean Derivation Function Used - Boolean [<Bob>] I think adding just those two functions is useful. Observation: Prediction resistance applies to all SP800-90(A) DRBGs, whereas the derivation function is only for cipher based DRBGs. Also, as an aside, if we are enumerating the various SP800-90(A) DRBG types, I assert we should leave off the Dual_EC DRBGs, if that hasn't already been considered. ;-> Thanks, Bob

On 14/12/2013 9:51 AM, Burns, Robert wrote: > If we added the following into RNG Parameters that would cover off on what is currently noted in the validation lists: > Prediction Resistance Enabled - Boolean > Derivation Function Used - Boolean > > [<Bob>] I think adding just those two functions is useful. Observation: Prediction resistance applies to all SP800-90(A) DRBGs, whereas the derivation function is only for cipher based DRBGs. > > Also, as an aside, if we are enumerating the various SP800-90(A) DRBG types, I assert we should leave off the Dual_EC DRBGs, if that hasn't already been considered. ;-> I think they should remain with enumeration values specified (like we have for other enumerations) and perhaps we could include a usage guide note on the issue if someone can come up with acceptable wording for such a note. We haven't made any specific recommendations in terms algorithms to not use within KMIP to date and remember we do list DES and things like RC2 within the algorithm list - see 9.1.3.2.13 within the KMIP 1.2 committee specification draft. Tim.

> > Also, as an aside, if we are enumerating the various SP800-90(A) DRBG > types, I assert we should leave off the Dual_EC DRBGs, if that hasn't > already been considered. ;-> > > I think they should remain with enumeration values specified ... We > haven't made any specific recommendations in terms algorithms to not > use within KMIP to date and remember we do list DES and things like RC2 > within the algorithm list - see 9.1.3.2.13 within the KMIP 1.2 > committee specification draft. Well... maybe we ought to remove (or at least deprecate) those, too. Why include anything that is known insecure? Shouldn't we, as a group, feel qualified to make a value judgment here? Or at least follow NIST guidance? Are there customer use cases out there involving (ahem) questionable crypto? I'd understand if we had a long 20-year history and lots of legacy apps... but I don't think we have that. Maybe I just get a Voldemort-like reaction to Dual_EC DRBG - "The algorithm that shall not be named". :-) My $0.02. -Mike

>Prediction Resistance from NIST SP 800-90. My reason for requesting inclusion of this is that we have some customers using PRNGs with Prediction Resistance ON. If we are going to return information about the PRNGs in use, then this is an important parameter for those customers. >NIST SP 800-90 Dual EC DRBG. There are some people who use this algorithm. As such, I don't think removing it outright is the correct thing to do. > DES.... Well... maybe we ought to remove (or at least deprecate) > those, too. Why include anything that is known insecure? Shouldn't we, as a > group, feel qualified to make a value judgment here? Or at least follow NIST > guidance? Deprecating the use of algorithms seems like a good idea, but where do we draw the line? Should we do this based on security strength? That is, anything with a security strength of 80 bits of less should be deprecated. Should we also advise anything with a security strength of 112 bits of less shouldn't be used in a new application (assuming your new application is going to stay in use post 2030 when 112 bit security strength is expected to be breakable)? Who feels confident assigning security strengths to all algorithms? For example we could say: Deprecated: Less than or equal to 80 bits of security strength: DES, RC2, MD2, MD4, MD5, Dual EC DRBG, FIPS 186 PRNG and RSA for key sizes less than or equal to 1024, EC with P160 curve. Deprecated for use in new applications: Between 80 and 112 bits of security strength: 3DES, SHA 224, RSA 2048, EC with P224 curve. Peter ------------------------------------------------ Peter Robinson - peter.robinson@rsa.com Senior Engineering Manager RSA, The Security Division of EMC - http://www.rsa.com/ Level 11, Central Plaza One, 345 Queen Street, Brisbane, Queensland 4000, AUSTRALIA. Phone: +61 7 3032 5253, Mobile: +61 407 962 150. -----Original Message----- From: kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ] On Behalf Of Mike Yoder Sent: Saturday, 14 December 2013 11:15 AM To: Tim Hudson; kmip@lists.oasis-open.org Subject: RE: [kmip] KMIP: RNG Proposals > > Also, as an aside, if we are enumerating the various SP800-90(A) > > DRBG > types, I assert we should leave off the Dual_EC DRBGs, if that hasn't > already been considered. ;-> > > I think they should remain with enumeration values specified ... We > haven't made any specific recommendations in terms algorithms to not > use within KMIP to date and remember we do list DES and things like > RC2 within the algorithm list - see 9.1.3.2.13 within the KMIP 1.2 > committee specification draft. Well... maybe we ought to remove (or at least deprecate) those, too. Why include anything that is known insecure? Shouldn't we, as a group, feel qualified to make a value judgment here? Or at least follow NIST guidance? Are there customer use cases out there involving (ahem) questionable crypto? I'd understand if we had a long 20-year history and lots of legacy apps... but I don't think we have that. Maybe I just get a Voldemort-like reaction to Dual_EC DRBG - "The algorithm that shall not be named". :-) My $0.02. -Mike --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

> Deprecating the use of algorithms seems like a good idea, but where > do we draw the line? Should we do this based on security Indeed, where do we draw the line? One client's secure algorithm is another client's insecure algorithm. Make recommendations. Provide guidance. Do not introduce weaknesses, and vulnerabilities into the standard. Build ease of use into the standard; i.e. be secure by default, and force clients to explicitly change the default, or standard way of doing things, in order to be insecure. Algorithm selection is best left to the client, or the server policy/configuration manager. Supporting "insecure" algorithms does not necessarily mean insecure operation will result. Same as limiting support to only "secure" algorithms does not mean secure operation will result. John -----Original Message----- From: kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ] On Behalf Of Robinson, Peter (RSA Engineering) Sent: Monday, 16 December 2013 10:06 AM To: Mike Yoder; Tim Hudson; kmip@lists.oasis-open.org Subject: RE: [kmip] KMIP: RNG Proposals >Prediction Resistance from NIST SP 800-90. My reason for requesting inclusion of this is that we have some customers using PRNGs with Prediction Resistance ON. If we are going to return information about the PRNGs in use, then this is an important parameter for those customers. >NIST SP 800-90 Dual EC DRBG. There are some people who use this algorithm. As such, I don't think removing it outright is the correct thing to do. > DES.... Well... maybe we ought to remove (or at least deprecate) > those, too. Why include anything that is known insecure? Shouldn't we, as a > group, feel qualified to make a value judgment here? Or at least follow NIST > guidance? Deprecating the use of algorithms seems like a good idea, but where do we draw the line? Should we do this based on security strength? That is, anything with a security strength of 80 bits of less should be deprecated. Should we also advise anything with a security strength of 112 bits of less shouldn't be used in a new application (assuming your new application is going to stay in use post 2030 when 112 bit security strength is expected to be breakable)? Who feels confident assigning security strengths to all algorithms? For example we could say: Deprecated: Less than or equal to 80 bits of security strength: DES, RC2, MD2, MD4, MD5, Dual EC DRBG, FIPS 186 PRNG and RSA for key sizes less than or equal to 1024, EC with P160 curve. Deprecated for use in new applications: Between 80 and 112 bits of security strength: 3DES, SHA 224, RSA 2048, EC with P224 curve. Peter ------------------------------------------------ Peter Robinson - peter.robinson@rsa.com Senior Engineering Manager RSA, The Security Division of EMC - http://www.rsa.com/ Level 11, Central Plaza One, 345 Queen Street, Brisbane, Queensland 4000, AUSTRALIA. Phone: +61 7 3032 5253, Mobile: +61 407 962 150. -----Original Message----- From: kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ] On Behalf Of Mike Yoder Sent: Saturday, 14 December 2013 11:15 AM To: Tim Hudson; kmip@lists.oasis-open.org Subject: RE: [kmip] KMIP: RNG Proposals > > Also, as an aside, if we are enumerating the various SP800-90(A) > > DRBG > types, I assert we should leave off the Dual_EC DRBGs, if that hasn't > already been considered. ;-> > > I think they should remain with enumeration values specified ... We > haven't made any specific recommendations in terms algorithms to not > use within KMIP to date and remember we do list DES and things like > RC2 within the algorithm list - see 9.1.3.2.13 within the KMIP 1.2 > committee specification draft. Well... maybe we ought to remove (or at least deprecate) those, too. Why include anything that is known insecure? Shouldn't we, as a group, feel qualified to make a value judgment here? Or at least follow NIST guidance? Are there customer use cases out there involving (ahem) questionable crypto? I'd understand if we had a long 20-year history and lots of legacy apps... but I don't think we have that. Maybe I just get a Voldemort-like reaction to Dual_EC DRBG - "The algorithm that shall not be named". :-) My $0.02. -Mike --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

> > >NIST SP 800-90 Dual EC DRBG. > There are some people who use this algorithm. As such, I don't think > removing it outright is the correct thing to do. Fair enough. There is a reasonable argument that says that even the "undesirable" algorithms should have a place, just so the client knows exactly what they're in for. > > DES.... Well... maybe we ought to remove (or at least deprecate) > > those, too. Why include anything that is known insecure? Shouldn't > we, as a > > group, feel qualified to make a value judgment here? Or at least > follow NIST guidance? > > Deprecating the use of algorithms seems like a good idea, but where do > we draw the line? Should we do this based on security strength? A first pass would be to just copy NIST's 800-131a document, which is your deprecated list. > For example we could say: > > Deprecated: Less than or equal to 80 bits of security strength: DES, > RC2, MD2, MD4, MD5, Dual EC DRBG, FIPS 186 PRNG and RSA for key sizes > less than or equal to 1024, EC with P160 curve. And by this you mean that the algorithms would still be selectable, but noted in the standard as being deprecated, I assume? > Deprecated for use in new applications: Between 80 and 112 bits of > security strength: 3DES, SHA 224, RSA 2048, EC with P224 curve. Hmmm. I would be on board with this in theory, but putting RSA 2048 on that list basically requires a transition to EC to go higher given the performance of RSA 4096. A good thing, but rather bold. It might be considered overreach. John Leiseboer wrote: > Indeed, where do we draw the line? One client's secure algorithm is > another client's insecure algorithm. Make recommendations. Provide > guidance. Do not introduce weaknesses, and vulnerabilities into the > standard. Build ease of use into the standard; i.e. be secure by > default, and force clients to explicitly change the default, or > standard way of doing things, in order to be insecure. I agree with this. But...for the sake of argument let's take an extreme case - DES. Crackable in under 24 hours at cloudcracker (MS-CHAPv2) for something like $17. Should we allow clients to impale themselves upon it? Thinking back on this, (and contradicting my previous paragraph) I realize that I'm coming at this argument from a user interface point of view, where simplicity and removing everything that's not needed are good things. But perhaps this isn't the way to go for a standard such as KMIP, where we've got to support a wide variety of behaviors amongst clients / servers. This means we have to leave everything in, but we can at least provide guidance... -Mike

Howdy everyone! IMHO, we should leave the decision to use something deprecated (in terms of RNG algorithms) to folks who integrate solutions that utilize KMIP. One thought from a Systems Engineering perspective, we should be careful not to remove capability (ie deprecated RNG algorithms). Given that KMIP is effectively a "data contract" for utilizing, managing, and distributing encryption keys, I think it is better not to take anything away. This also has added benefit in helping those who adopt KMIP in the future to have a capacity for transition if they are currently using deprecated RNG algorithms. In other words, let KMIP be a bridge to better security vs a barrier to getting there. The downside is that you are giving folks enough rope to hang themselves in terms of enabling use of algorithms that compromise security. Thanks! Chuck -----Original Message----- From: kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ] On Behalf Of Mike Yoder Sent: Monday, December 16, 2013 2:39 AM To: Robinson, Peter (RSA Engineering); Tim Hudson; kmip@lists.oasis-open.org Subject: RE: [kmip] KMIP: RNG Proposals > > >NIST SP 800-90 Dual EC DRBG. > There are some people who use this algorithm. As such, I don't think > removing it outright is the correct thing to do. Fair enough. There is a reasonable argument that says that even the "undesirable" algorithms should have a place, just so the client knows exactly what they're in for. > > DES.... Well... maybe we ought to remove (or at least deprecate) > > those, too. Why include anything that is known insecure? Shouldn't > we, as a > > group, feel qualified to make a value judgment here? Or at least > follow NIST guidance? > > Deprecating the use of algorithms seems like a good idea, but where do > we draw the line? Should we do this based on security strength? A first pass would be to just copy NIST's 800-131a document, which is your deprecated list. > For example we could say: > > Deprecated: Less than or equal to 80 bits of security strength: DES, > RC2, MD2, MD4, MD5, Dual EC DRBG, FIPS 186 PRNG and RSA for key sizes > less than or equal to 1024, EC with P160 curve. And by this you mean that the algorithms would still be selectable, but noted in the standard as being deprecated, I assume? > Deprecated for use in new applications: Between 80 and 112 bits of > security strength: 3DES, SHA 224, RSA 2048, EC with P224 curve. Hmmm. I would be on board with this in theory, but putting RSA 2048 on that list basically requires a transition to EC to go higher given the performance of RSA 4096. A good thing, but rather bold. It might be considered overreach. John Leiseboer wrote: > Indeed, where do we draw the line? One client's secure algorithm is > another client's insecure algorithm. Make recommendations. Provide > guidance. Do not introduce weaknesses, and vulnerabilities into the > standard. Build ease of use into the standard; i.e. be secure by > default, and force clients to explicitly change the default, or > standard way of doing things, in order to be insecure. I agree with this. But...for the sake of argument let's take an extreme case - DES. Crackable in under 24 hours at cloudcracker (MS-CHAPv2) for something like $17. Should we allow clients to impale themselves upon it? Thinking back on this, (and contradicting my previous paragraph) I realize that I'm coming at this argument from a user interface point of view, where simplicity and removing everything that's not needed are good things. But perhaps this isn't the way to go for a standard such as KMIP, where we've got to support a wide variety of behaviors amongst clients / servers. This means we have to leave everything in, but we can at least provide guidance... -Mike --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

> > >NIST SP 800-90 Dual EC DRBG. > There are some people who use this algorithm. As such, I don't think > removing it outright is the correct thing to do. [<[Bob]>] Peter -- quite right and let me rephrase my suggestion -- it is clear that the next version of SP800-90A will *not* include a definition of Dual EC DRBG. So my feeling is that however we're structuring the documentation and/or enumeration definitions, we should not be implying that Dual EC DRBG is an SP800-90A approved algorithm. We should (somehow) let the spec readers know that this algorithm was specified in an 'earlier' SP800-90 document, and is no longer approved/approvable. Of course this could be done in many ways, and I'm quite loathe to open up any sort of discussion about how to version stuff in enums, but at a minimum, the documentation should be authored to ensure that the reader gets a clear indication that the mechanism in question is no longer a NIST SP800-90A approvable mechanism. And fully agreed that we are not really in a position to state what is 'secure' and what is 'insecure'. Thanks, Bob