ospf authernitication

[fabio.marino]

Hi,

does anyone know what the meaning of the optional field  [ 0 | 3 | 7 ] for the opsf authentication?

•ip ospf message-digest-key key-id md5 [ 0 | 3 | 7 ] key

I read tha for example:

7	(Optional) Specifies a Cisco type 7 encrypted password to generate the MD5 key.

but in a few words what does it mean?

When should we use these optonals value in the autherntication process?

Honestly I did not find any clear explanation about this topic.

Thanks!!

[Karsten Iwen · Accepted solution]

That is the type of the key. The "traditional values" are 0 or 7.

• 0 means that the following key is really the plaintext key.
• 7 means that the following key is "encrypted" with Ciscos own mechanism ("service password-encryption", more or less against shoulder-surfing then an encryption as it is reverible).
• The newer type 3 is a key that's based on a 3des encryption. I'm only aware of NX-OS doing that.

In other platforms and commands you'l see also other types:

• 4: sha256 hashed password
• 6: encrypted PSKs in VPNs

These different types don't change how the IOS-function is used, ospf authentication is the same regardless if you use 0, 3 or 7. But the local representation in the config and the way how the key/password is saved in the config is controlled by that type.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[fabio.marino]

Hi Karsten,

Many thanks.

[Peter Paluch]

Hi Fabio,

To add to Karsten's perfect reply, the number is there for the router, not for you as an administrator. The router simply needs to know if the password in the particular command is entered in the plaintext form, or whether it is cryptographically protected - and if it is, how exactly. In other words, we are talking about how the password is stored in the configuration. It does not influence how the router uses the password to authenticate itself. You as a person always enter the password in the plaintext form. The only way of you entering the password already in an encrypted form would be when retaking it from a different configuration.

Karsten - you probably know that already, but if not, you may be interested that Type-4 passwords have a major implementation flaw (the mechanism is cryptographically okay but IOS programmers obviously botched the implementation) and are deprecated.

http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20130318-type4

Best regards,

Peter

[fabio.marino]

Hi Peter,

Really appreciate your answer, it is very useful.

But now  I have doubts :-)

Let´s assume I am entering a password already in an encripcted form (copied from a different configuration), in this case I do not have to enter one of the optional fields  [ 0 | 3 | 7 ].

Am I correct?

[Karsten Iwen]

If you do a "show run", the config-line gives the correct type that is needed to copy the key to a different router (well, type 6 is an exception here).

Example:

ip ospf message-digest-key 1 md5 7 12232...

This line is from a running config. The typr is 7 as the key is stored in the config in an "encrypted" form. This line can directly be taken and copied to a different router. If you woulf change the type 7 to 0, then "1223..." would be the new password and again be encrypted.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[fabio.marino]

Yep!!

Many many thanks!!!!

[Karsten Iwen]

Karsten - you probably know that already, but if not, you may be interested that Type-4 passwords have a major implementation flaw (the mechanism is cryptographically okay but IOS programmers obviously botched the implementation) and are deprecated.

yes, but I'm not aware at the moment if the intended PBKDF2-based implementation is already available. Any information on that?

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[Peter Paluch]

Hi Karsten,

yes, but I'm not aware at the moment if the intended PBKDF2-based implementation is already available. Any information on that?

I haven't heard about anything, sadly. You know, I find this strange... someone during the coding stage forgets to call the PBKDF2 with the salt, or the call to the function is not done properly - okay, the Type-4 passwords are therefore mere SHA-256 hashes of the original password, so let's deprecate them. But why, after this issue has been identified, no one promptly suggests a Type-X password that use the corrected call to PBKDF2? They wanted to get it correct the first time, they failed (although I wonder how this could have happened, as this is a mistake that should not happen even to an IT student bringing in a trivial seminal thesis using stored passwords), so why don't they just correct it now they know what they screwed up, and release it again?

The software development in Cisco, I hate to say this, is getting from bad to worse. Noting the number of issues with the Catalyst 2960/3560/3750 IOSes discussed here on CSC, the latest issue with the DHCP Snooping - I am just shaking my head. Something is seriously wrong, and I am honestly worried.

Best regards,

Peter

[Karsten Iwen]

Oh yes, sometimes I also ask myself how some things can happen, and Cisco for sure has sometimes quality-problems. But still, in general it works quite good ...

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni