RIP MD5 authentication – mismatch in key ID

This is an interesting fact I just found out. When we configure MD5
authentication for RIP they key-ID and key-string must match, this is
well known. But what happens if we actually configure the wrong key-ID?
Take a look at the following config.

R1#sh run | s key chain
key chain RIP
 key 1
   key-string cisco

R2#sh run | s key chain
key chain RIP
 key 2
   key-string cisco

So R2 has a higher key-ID. No routes should be passing right? Wrong.
R2 will accept routes from R1 because it has the higher ID however
R1 will not accept routes from R2.

R1#show ip route rip

RIP: ignored v2 packet from 10.10.1.2 (invalid authentication)

R2#show ip route rip
     1.0.0.0/24 is subnetted, 1 subnets
R       1.1.1.0 [120/1] via 10.10.1.1, 00:00:26, FastEthernet0/0

RIP: received packet with MD5 authentication

The only thing I can think of why this works is that it is some form
of rollover process where they older key-ID is accepted until routers
have been migrated to the new ID. It is strange that it works though
since key-ID 1 does not exist on R2.

If we change the password on R1 then the authentication will fail on R2
also.

RIP: ignored v2 packet from 10.10.1.1 (invalid authentication)

So the password is surely checked but they key-ID is ignored if a higher
key-ID is locally configured.

If anyone has some background on this I would be very interested. All I
could find was a RFC for MD5 for RIP. It mentioned something about key rollover
but nothing definite.