[anonsec] question: ID payload in BTNS IKE negotiation

[Shinta Sugimoto]

Hello,

I have a basic question about BTNS IKE negotiation.

In BTNS IKE negotiation, what should ID payload (IDi/IDr) be?
I understand that public key is the instance which represents
identity of the host in BTNS. But reading the spec, I did not fully
understand how IKE negotiation is done in particular usage of ID
payload. My interpretation of the spec is that an identity of
a peer (=public key) is represented by the CERT payload. If so,
what is the role of ID payload in BTNS IKE negotiation?
And what should be included in the IDi, IDr?

Thank you in advance.

Regards,
Shinta

[Michael Richardson]

Post by Shinta Sugimoto
In BTNS IKE negotiation, what should ID payload (IDi/IDr) be?
I understand that public key is the instance which represents
identity of the host in BTNS. But reading the spec, I did not fully

To first order, it shouldn't matter, however that will lead to
interoperability issues.

My suggestion is that it should be IPV4/IPV6_ID of the host.

Post by Shinta Sugimoto
understand how IKE negotiation is done in particular usage of ID
payload. My interpretation of the spec is that an identity of
a peer (=public key) is represented by the CERT payload. If so,
what is the role of ID payload in BTNS IKE negotiation?
And what should be included in the IDi, IDr?

The ID payload tells you how to look up the policy in the PAD.
You will have to look into the PAD at least, to discover that you had no
explicit policy for this peer, and that therefore, it should be put into
"BTNS" category.

[Shinta Sugimoto]

Hello Michael,

Thank you for the response. Please find my comments inline.

On Sun, 13 May 2007 19:51:50 -0400

Post by Michael Richardson

Post by Shinta Sugimoto
In BTNS IKE negotiation, what should ID payload (IDi/IDr) be?
I understand that public key is the instance which represents
identity of the host in BTNS. But reading the spec, I did not fully

To first order, it shouldn't matter, however that will lead to
interoperability issues.

I see. So the spec should be clear on this point.

Post by Michael Richardson
My suggestion is that it should be IPV4/IPV6_ID of the host.

Hmm. This seems to me fine for static and/or single-homed environment,
but not ideal for mobile and/or multihomed environment (e.g. RFC 4555)
where IP address is not suitable for the purpose of identifying peers.
So, I think it would be better to use something different than IP
address for ID payload although I don't have good answer either at the
moment.

Post by Michael Richardson

Post by Shinta Sugimoto
understand how IKE negotiation is done in particular usage of ID
payload. My interpretation of the spec is that an identity of
a peer (=public key) is represented by the CERT payload. If so,
what is the role of ID payload in BTNS IKE negotiation?
And what should be included in the IDi, IDr?

The ID payload tells you how to look up the policy in the PAD.

Yes, that is true. And the use of identifier which is based on
IP address (ID_IPV4_ADDR/ID_IPV6_ADDR) will limit the applicability
of BTNS to static/single-homed environment as I mentioned above.

Post by Michael Richardson
You will have to look into the PAD at least, to discover that you had no
explicit policy for this peer, and that therefore, it should be put into
"BTNS" category.

Yes.

I still need clarification of the intention of BTNS spec for ID. The

Post by Michael Richardson
2. BTNS
The IPsec processing model, IKE and IKEv2 are hereby modified as
o A new ID type is added, 'PUBLICKEY'; IDs of this type have public
keys as values. This ID type is not used on the wire.

I assume that the above sentence recommends not to use ID_PUBLICKEY as
an ID payload. If so, what is the reason behind? I see that it
(including ID_PUBLICKEY in ID payload) would simply be a duplication
because the public key is to be stored in CERT payload, but I believe
it still makes sense to use ID type which is independent from IP address
for ID payload. Any comments?


Regards,
Shinta

[Michael Richardson]

mcr> My suggestion is that it should be IPV4/IPV6_ID of the host.

Post by Shinta Sugimoto
Hmm. This seems to me fine for static and/or single-homed environment,
but not ideal for mobile and/or multihomed environment (e.g. RFC 4555)
where IP address is not suitable for the purpose of identifying peers.
So, I think it would be better to use something different than IP
address for ID payload although I don't have good answer either at the
moment.

Unless you propose to move during the lifetime of the connection, this
concern does not apply.

If you do move, then you establish a new SA. You use your new address.
This is BTNS, you don't need long-term credential for PAD lookup. That's the
whole point.

If you are multihomed, and you might switch prefix, then you probably want
MOBIKE, at which point, you might be able to propose multiple addresses.

Post by Shinta Sugimoto
Yes, that is true. And the use of identifier which is based on
IP address (ID_IPV4_ADDR/ID_IPV6_ADDR) will limit the applicability
of BTNS to static/single-homed environment as I mentioned above.

I disagree strongly. It works just fine.

Post by Shinta Sugimoto

Post by Michael Richardson
2. BTNS
The IPsec processing model, IKE and IKEv2 are hereby modified as
o A new ID type is added, 'PUBLICKEY'; IDs of this type have public
keys as values. This ID type is not used on the wire.

I assume that the above sentence recommends not to use ID_PUBLICKEY as
an ID payload. If so, what is the reason behind? I see that it

Because it's just an entry in the PAD.

Post by Shinta Sugimoto
(including ID_PUBLICKEY in ID payload) would simply be a duplication
because the public key is to be stored in CERT payload, but I believe
it still makes sense to use ID type which is independent from IP address
for ID payload. Any comments?

You are now assuming that both ends know that they are doing BTNS.
A number of the models assume that one end has strong authentication for the
other end, in which case, it would expect something specific in the ID field.

Note that each end may have independent notions of whether or not the peer
will strongly authenticate it. As long as the public keys are present in a
CERT payload, we do not have to tell the peers what mode of BTNS they are in.
It may be that we will get strong authentication because the administrators
of both peers have configured keys into their trusted store after checking
fingerprints over the phone, in PGP signed email, etc.