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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>