Subject: [anonsec] question: ID payload in BTNS IKE negotiation

From: shinta at sfc.wide.ad.jp (Shinta Sugimoto)
Date: Sun, 13 May 2007 23:10:52 +0900

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

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Sun, 13 May 2007 19:51:50 -0400

> 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.

> 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.

---

From: shinta at sfc.wide.ad.jp (Shinta Sugimoto)
Date: Mon, 14 May 2007 16:59:53 +0900

Hello Michael,

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

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

> To first order, it shouldn't matter, however that will lead to 

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

> 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.

> 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.

> explicit policy for this peer, and that therefore, it should be put into

Yes.

I still need clarification of the intention of BTNS spec for ID.  The
spec (draft-btns-core-02) says:

> 2.  BTNS
> 
>    The IPsec processing model, IKE and IKEv2 are hereby modified as
>    follows:
> 
>    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

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 24 May 2007 11:07:25 -0400

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

> address for ID payload although I don't have good answer either at the

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.

> of BTNS to static/single-homed environment as I mentioned above.

I disagree strongly. It works just fine.

> an ID payload.  If so, what is the reason behind?  I see that it

Because it's just an entry in the PAD.

> 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.