Crypto Algorithms and Concerns Discussion

[ciscomoderator]

This is an opportunity to learn and discuss more about the subjects that will be discussed In the corresponding BRKSEC3074 techtorial session in Cisco Live 2010. That session will focus on cryptographic algorithms and techniques that provide security features. It will also address concerns on the methods presented,  describe recommended practices and algorithm choices and try to address what is going to come in the future.

We would like to encourage attendees to pose their questions on specific theoretical or Cisco focused issues relevant to the subjects presented in the session by Panos Kampanakis. Panos has extensive Security technologies exposure and has extensively worked on Cryptography and network security. He will try to address questions in a timely manner and he hopes this discussion will serve as a constructive add-on to the 2 hour presentation.

Panos might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through July 3rd, 2010. Visit this forum often to view responses to your questions and the questions of other community members.

[Panos Kampanakis]

Is there a news letter that covers things like WEP is now
bad etc???

Would be great to have one that says things like that and
that the new ASA code 8.7 is now supporting AES512 or something.

For the first part, there could be multiple publications that mention the vulneratbilities of WEP. If I had to give you a couple I would suggest US CERT's http://www.us-cert.gov/cas/tips/ST05-003.html National Cyber Alert System Cyber Security Tip ST05-003 that mentions "WEP (Wired Equivalent Privacy) and WPA (Wi-Fi Protected Access) both encrypt information on wireless devices. However, WEP has a number of security issues that make it less effective than WPA, so you should specifically look for gear that supports encryption via WPA. Encrypting the data would prevent anyone who might be able to access your network from viewing your data (see Understanding Encryption for more information).".And also from NIST http://csrc.nist.gov/publications/nistpubs/800-48-rev1/SP800-48r1.pdf "WEP has several significant security problems, most of which cannot be solved by reconfiguration of WEP itself. For example, increasing the length of the WEP key would only marginally increase the time needed to decrypt packets. WEP does not provide an acceptable level of wireless transmission security, so it should not be the sole security mechanism used in legacy IEEE 802.11 WLAN deployments. More robust WLAN security solutions, such as those outlined in NIST SP 800-97,10 or compensating controls should be implemented to provide the needed security. Because of the serious security flaws in the legacy IEEE 802.11 standard, NIST recommends that organizations with existing legacy IEEE 802.11 WLAN implementations develop and implement migration strategies to move to IEEE 802.11i, which offers better security."

As for the ASA it can support all AES128, 192, 256 in all versions http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/c5.html#wp2225713

If you arefering to AES password encryptio, then yes it was introduced in 8.2 http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/basic.html#wp1087800

I hope it helps.

PK

[Panos Kampanakis]

im looking for
future information

regarding what we should and should not be
deploying.  One instance

would be if a new encryption method is coming out or last
say that a

vulnerability is discovered for sha-2.  is there a Cisco newsletter

that would cover this?

All Cisco responses on vulnerabilities coming out are here http://www.cisco.com/en/US/products/products_security_advisories_listing.html

There is an RSS feed for it also.

I believe that will covers.

PK

[Panos Kampanakis]

Primarily one
question at this time - I always understood non-repudiation as a function to
prove that the sender of a message was indeed the sender and that the sender of
a message did send that particular message at or near the time that I received
it (assuming no significant delays during transit). The session yesterday
provided a bit of a different interpretation. Just wanted to see if my initial
interpretation was correct and the misunderstanding was unwarranted or if I
should do some additional research on the subject.

The truth is that as you are suggesting non-repudiation goes hand in hand with authentication. In other words it often means that someone cannot claim that he did not sign some message. Or that someone cannot replay a singed message and have the other party use it as a legal authenticated message. To provide the above we need authentication (signatures) and some way verifying that some message is not replayed. That is often achieved with challenges, nonces etc.

So, what you are saying is right. “the sender of a message was indeed the sender” is the authentication, and “ that the sender of a message did send that particular message at or near the time that I received it (assuming no significant delays during transit)” is the replay protection part. The slide in the preso and what I explained was mostly focused on the “replay protection” for non-repudiation because the authentication was already mentioned separately.

I hope it makes sense.

PK