I would like to note that there is pre-existing work in this area (http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-07.txt, http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt). Be that as it may, however, it's difficult to understand what the purpose of the Requesting Entity's Identity in the express environment that is implied by the draft (i.e., a request from a visited network to a home network). If, as I assume (please correct me if my assumption is incorrect), the requesting entity is a NAS it doesn't seem reasonable to believe that the RADIUS server in a remote network would have any knowledge of it, even less so in the case where the visited and home networks are separated by one or more proxies & thus lack any direct trust relationship. If this identity is meant to be used for key binding purposes, I think that this is incredibly dangerous, imputing trust as it does between the home RADIUS server and an entity of which it possesses no knowledge. OTOH, suppose that there _is_ a direct trust relationship between the home & visited network, intervening proxies notwithstanding (perhaps by means of an OOB WRT RADIUS key exchange); further, suppose that this trust is so strong that the home RADIUS server is willing to take the visited domain at its word as to the identity of the requesting NAS. In this case, the security of the protocol is defeated by the use of IPsec on a hop-by-hop basis since the message and key are available in plaintext form at each (less trusted) hop.