IDS> Min_Cipher_Suite and Min_Cipher_Key_Length attributes

IDS> Min_Cipher_Suite and Min_Cipher_Key_Length attributes

IDS> Min_Cipher_Suite and Min_Cipher_Key_Length attributes

Brian Smithson brian.smithson at ricoh-usa.com
Mon Feb 2 14:05:59 EST 2009


I agree that we may have bitten off more than we can (or should) chew
with the cipher suite/length attributes. It's a general security problem
that applies to all kinds of devices. Until it is solved by a wider
community, perhaps 3rd party certification or customer configuration
attributes would be the best choice to allow customers to set and
enforce policies having to do with encryption etc.

--
Regards,
Brian Smithson
PM, Security Research
PMP, CISSP, CISA, ISO 27000 PA
Advanced Imaging and Network Technologies
Ricoh Americas Corporation
(408)346-4435



Randy Turner wrote:
>
> This was basically my feeling when I was considering exactly what we
> were proposing...
>
> If we're trying to come up with a minimum security level for a
> hardcopy device, then it needs
> to be expressed or modeled after something that can be applied
> generally to all security functionality
> within the device, otherwise we've left something out, and if we've
> left something out, how valuable
> is the "minimum security" assurance if there's a gaping hole somewhere
> in a device that we didn't take
> into account.
>
> If if we just address encryption, we've left out digital signatures
> and certificate validation.
>
> Some devices, when they receive an SSL server cert, may not even do
> any validation on that cert, or
> they may only do time-stamp checks but not revocation checks (like
> some browsers were known to do).
> I would consider this a fairly major security issue.  And this is just
> one example.
>
> So I guess what I'm saying is that coming up with a minimum security
> "profile" for a device is going to
> be a "sticky wicket",  and would probably end up consisting of several
> multi-valued attributes potentially.
>
> I'm beginning to re-think our earlier discussion about having an
> attribute that says that this device has
> been "certified" to a particular assurance level or minimum security
> profile, by a 3rd party.  And just setting
> this attribute to "yes" or "no".  And let the 3rd party certification
> house worry about actually examining all
> the cryptography in the product to see if it meets some standard.
>
> And Dave, regarding your analysis of missing enums (Counter mode),
> there are enumerations for GCM,
> which is "Galois Counter Mode". I don't expect any other form of
> counter mode to be added anytime soon, at
> least it's not under discussion on the mailing lists. But you bring up
> the larger point of applicability of our attributes,
> which I hope I have articulated further in this email.
>
> Thanks,
> Randy
>
>
> On Feb 2, 2009, at 7:50 AM, Dave Whitehead wrote:
>
>> I think it should be a "general" statement since there are other
>> applications that may not use TLS.
>>
>> Also, the IANA registry for TLS cipher suites does not seem to cover the
>> entire universe.  For example, there are no enumerations for AES in
>> Counter
>> mode.  (Or maybe I'm just having problems finding them ...)  How
>> would we
>> specify 128-bit AES in CTR mode?
>>
>> That said, and accounting for Ira's definition of "secure," I'm
>> wondering
>> if we need more information.  Should we attach security parameters to
>> individual applications? (ouch!)  Should the Min_Cipher_Suite element
>> be a
>> list of application:ciphersuite entries?
>>
>> Or, should we just throw up our hands and say this is larger than
>> just MFDs
>> and should be handled somewhere else?
>>
>> dhw
>>
>> David H. Whitehead
>> Development Engineer
>> Lexmark International, Inc.
>> 859.825.4914
>> davidatlexmarkdotcom
>>
>>
>>
>>             Randy Turner
>>             <rturner at amalfisy
>>            
>> stems.com>                                                 To
>>             Sent by:                  ids at pwg.org
>>            
>> owner-ids at pwg.org                                          cc
>>
>>                                                                  
>> Subject
>>             02/01/2009 11:30          Re: IDS> Min_Cipher_Suite and
>>             PM                        Min_Cipher_Key_Length attributes
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I have a scope question,
>>
>> Using our "minimum security" attribute(s), do we want to specify the
>> minimum cryptographic strength
>> for just hardcopy applications using TLS/SSL?   Or do we want to give
>> "general" guidance no matter
>> what protocol the device uses when performing cryptography?
>>
>> Certainly SSL/TLS would knock out a good bit, but I was wondering
>> about other cryptographic applications on a
>> device that might not use SSL/TLS as it's cryptographic session
>> establishment protocol.
>>
>> ?
>>
>> R.
>>
>> On Feb 1, 2009, at 7:29 PM, Ira McDonald wrote:
>>
>>> Hi Randy,
>>>
>>> Sorry - agreed - the key length, encryption algorithm (DES),
>>> and mode (CBC) are all in the single TLS token.
>>>
>>> Cheers,
>>> - Ira
>>>
>>> Ira McDonald (Musician / Software Architect)
>>> Chair - Linux Foundation Open Printing WG
>>> Blue Roof Music/High North Inc
>>> email: blueroofmusic at gmail.com
>>> winter:
>>> 579 Park Place  Saline, MI  48176
>>> 734-944-0094
>>> summer:
>>> PO Box 221  Grand Marais, MI 49839
>>> 906-494-2434
>>>
>>>
>>>
>>> On Sun, Feb 1, 2009 at 9:49 PM, Randy Turner <rturner at amalfisystems.com
>>>> wrote:
>>>>
>>>> All I'm saying is if you want to use TLS/SSL enumerations to
>>>> designate
>>>> cryptoalgorithms, then
>>>> use don't need the minimum key length because the key length is
>>>> included in
>>>> the enumeration.
>>>>
>>>> Randy
>>>>
>>>>
>>>> On Feb 1, 2009, at 6:40 PM, Ira McDonald wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Randy - you missed my point - EVERY open port on the whole device
>>>>> has to use TLS/SSL (or SSH or whatever) with the same minimum
>>>>> strength encryption algorithm (DES, 3DES, AES, etc.) and same
>>>>> minimum key length, or the device is *not secure* - period.
>>>>>
>>>>> Different encrytion and secure hash algorithms offer different
>>>>> strengths
>>>>> of protection when using the same key length.
>>>>>
>>>>> And I don't favor dropping the use of the IANA TLS registry - it's
>>>>> used
>>>>> by all SSL and TLS implementations and many other IETF protocols
>>>>> and can be reasonably mapped to other IANA security token
>>>>> registries.
>>>>>
>>>>> Cheers,
>>>>> - Ira
>>>>>
>>>>> Ira McDonald (Musician / Software Architect)
>>>>> Chair - Linux Foundation Open Printing WG
>>>>> Blue Roof Music/High North Inc
>>>>> email: blueroofmusic at gmail.com
>>>>> winter:
>>>>> 579 Park Place  Saline, MI  48176
>>>>> 734-944-0094
>>>>> summer:
>>>>> PO Box 221  Grand Marais, MI 49839
>>>>> 906-494-2434
>>>>>
>>>>>
>>>>> On Sun, Feb 1, 2009 at 7:16 PM, Randy Turner
>>>>> <rturner at amalfisystems.com
>>>>>>
>>>>> wrote:
>>>>>>
>>>>>> Scratch my comment about IKE (and IPSEC) below, as RFC 4308 seems
>>>>>> to
>>>>>> suggest
>>>>>> that IKE(and V2) use a multi-valued negotiation type which
>>>>>> indicates more
>>>>>> than just encryption strength....
>>>>>>
>>>>>> R.
>>>>>>
>>>>>>
>>>>>> On Feb 1, 2009, at 2:06 PM, Randy Turner wrote:
>>>>>>
>>>>>>>
>>>>>>> The "model" that we've discussed in the past is having a "scale"
>>>>>>> of
>>>>>>> cryptographic protection, from weak to strong.
>>>>>>> And based on the model, I think the idea of these attributes was
>>>>>>> to be
>>>>>>> able to specify a "minimum" cryptographic
>>>>>>> requirement for the device.
>>>>>>>
>>>>>>> The "model" that was originally referenced was that using SSL/
>>>>>>> TLS, and
>>>>>>> the
>>>>>>> corresponding TLS/SSL IANA enumerations.
>>>>>>>
>>>>>>> If we're going to stick to the SSL/TLS enumerations, then the
>>>>>>> minimum
>>>>>>> key-size wouldn't be needed because they offer no
>>>>>>> benefit to implementers - TLS/SSL only negotiates based on the
>>>>>>> enumerations and not a separate parameter called "key length". I
>>>>>>> believe
>>>>>>> (don't quote me on this) that IKE does the same thing when
>>>>>>> negotiating
>>>>>>> IPSEC security associations.
>>>>>>>
>>>>>>> If we're going to just have a "minimum" key length for
>>>>>>> encryption, then
>>>>>>> you wouldn't need to reference the enumerations.
>>>>>>>
>>>>>>> I think there are 4 alternatives:
>>>>>>>
>>>>>>> 1.  Just use a minimum key length, and we don't worry about a
>>>>>>> particular
>>>>>>> "model" for levels of encryption, such as SSL/TLS
>>>>>>>
>>>>>>> 2. Just use the enumerations from the TLS/SSL IANA registry, and
>>>>>>> dump
>>>>>>> the
>>>>>>> minimum key length.
>>>>>>>
>>>>>>> 3. Dump both and move on
>>>>>>>
>>>>>>> 4. Come up with a new proposal based on another set of
>>>>>>> enumerations
>>>>>>> describing cryptographic algorithms
>>>>>>>
>>>>>>> My preference would be 2 or 3, since the guidance and direction
>>>>>>> for
>>>>>>> implementers is very straightforward and unambiguous (being an
>>>>>>> OpenSSL implementer myself)
>>>>>>>
>>>>>>> Randy
>>>>>>>
>>>>>>>
>>>>>>> On Feb 1, 2009, at 10:52 AM, Ira McDonald wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Just my two cents, but, I'd urge that either:
>>>>>>>>
>>>>>>>> (1) Both attributes stay REQUIRED; or
>>>>>>>> (2) Both attributes are deleted entirely from IDS.
>>>>>>>>
>>>>>>>> Having said that, the FIRST principal of security
>>>>>>>> audits is that EVERY network protocol has to be
>>>>>>>> secured on a device and the weakest security
>>>>>>>> configured for any of those network protocols is
>>>>>>>> the security rating of the entire device.
>>>>>>>>
>>>>>>>> Secure devices do NOT send or receive unsecured
>>>>>>>> email over SMTP (for example).
>>>>>>>>
>>>>>>>> MFDs shouldn't claim to be secure if they aren't.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> - Ira
>>>>>>>>
>>>>>>>> Ira McDonald (Musician / Software Architect)
>>>>>>>> Chair - Linux Foundation Open Printing WG
>>>>>>>> Blue Roof Music/High North Inc
>>>>>>>> email: blueroofmusic at gmail.com
>>>>>>>> winter:
>>>>>>>> 579 Park Place  Saline, MI  48176
>>>>>>>> 734-944-0094
>>>>>>>> summer:
>>>>>>>> PO Box 221  Grand Marais, MI 49839
>>>>>>>> 906-494-2434
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Jan 31, 2009 at 7:08 PM, Randy Turner
>>>>>>>> <rturner at amalfisystems.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I think so....when you actually code TLS connections using
>>>>>>>>> OpenSSL,
>>>>>>>>> you
>>>>>>>>> can
>>>>>>>>> specify a minimum cipher suite to be negotiated...only the
>>>>>>>>> cipher
>>>>>>>>> suite
>>>>>>>>> enumeration is specified, so I think it's ok to use just the
>>>>>>>>> enumerations.
>>>>>>>>> R.
>>>>>>>>> On Jan 31, 2009, at 4:03 PM, Brian Smithson wrote:
>>>>>>>>>
>>>>>>>>> Thanks, Randy.
>>>>>>>>>
>>>>>>>>> So is our key length attribute redundant?
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Regards,
>>>>>>>>> Brian Smithson
>>>>>>>>> PM, Security Research
>>>>>>>>> PMP, CISSP, CISA, ISO 27000 PA
>>>>>>>>> Advanced Imaging and Network Technologies
>>>>>>>>> Ricoh Americas Corporation
>>>>>>>>> (408)346-4435
>>>>>>>>>
>>>>>>>>> Randy Turner wrote:
>>>>>>>>>
>>>>>>>>> Hi Brian,
>>>>>>>>> I think the IANA registry actually has the key length
>>>>>>>>> specified as
>>>>>>>>> part
>>>>>>>>> of
>>>>>>>>> the suite enumeration.
>>>>>>>>> Examples are:
>>>>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA256
>>>>>>>>> TLS_RSA_WITH_AES_256_CBC_SHA256
>>>>>>>>> There are other suites that don't specify numeric key sizes,
>>>>>>>>> but in
>>>>>>>>> these
>>>>>>>>> cases, the algorithm itself
>>>>>>>>> (3DES for example) work with a specific key size that doesn't
>>>>>>>>> vary.
>>>>>>>>> In this case, we may be able to just specify that we're
>>>>>>>>> talking about
>>>>>>>>> a
>>>>>>>>> minimum suite, with a reference to RFC 5246 and
>>>>>>>>> the IANA registry itself.
>>>>>>>>> Randy
>>>>>>>>>
>>>>>>>>> On Jan 30, 2009, at 6:26 PM, Brian Smithson wrote:
>>>>>>>>>
>>>>>>>>> I am still wondering how these two attributes can be used in
>>>>>>>>> practice.
>>>>>>>>> I
>>>>>>>>> know that we can uniquely identify cipher suites using the IANA
>>>>>>>>> registry, but is there an authoritative source to specify that
>>>>>>>>> one
>>>>>>>>> suite
>>>>>>>>> is "more minimum" than another? And if you consider different
>>>>>>>>> key
>>>>>>>>> lengths that might be acceptable for a given suite, then can
>>>>>>>>> we really
>>>>>>>>> say that suite X is more minimum than suite Y even if an HCD
>>>>>>>>> supports
>>>>>>>>> a
>>>>>>>>> relatively long key length for X but only supports a
>>>>>>>>> relatively short
>>>>>>>>> one for Y?
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Regards,
>>>>>>>>> Brian Smithson
>>>>>>>>> PM, Security Research
>>>>>>>>> PMP, CISSP, CISA, ISO 27000 PA
>>>>>>>>> Advanced Imaging and Network Technologies
>>>>>>>>> Ricoh Americas Corporation
>>>>>>>>> (408)346-4435
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>



More information about the Ids mailing list