Subject: [anonsec] BTNS work in pki4ipsec

From: Atul.Sharma at nokia.com ([email-masked])
Date: Thu Nov 18 05:53:39 2004

I will second Lars' objection of rolling BTNS work into PKI4IPSEC.
The former is about making things work without PKI, while the latter
is all about facilitating use of PKI specifically for IPsec. I do not 
see how we are going to address exactly opposite goals within the 
charter of one working group. I do not see how these two different
efforts with different goals are going to come up with proposals
conflicting with each other.

Atul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Lars Eggert
> Sent: Wednesday, November 17, 2004 5:43 PM
> To: Discussions of anonymous Internet security.
> Subject: Re: [anonsec] BTNS work in pki4ipsec
> 
> 
> Sam,
> 
> Sam Hartman wrote:
> > 
> > However when I discussed the results of the bof with Russ 
> Housley, he
> > pointed out that this work could happen in the pki4ipse 
> working group
> > if that group is rechartered.  That seems to be a better 
> direction for
> > the work.  Both Russ and I believe that having two working groups
> > specifying how IPsec interacts with the (lack of) a PKI would be
> > problematic.
> 
> to make this work, pki4ipsec would need to recharter to include the 
> exact opposite of what they are currently working on. They 
> work on the 
> specifics of how to integrate existing IPsec with a PKI. BTNS, on the 
> other hand, would work on how to use IPsec *without* a PKI. I 
> don't see 
> how these two very different work items could successfully be 
> tackled by 
> a single WG.
> 
> Lars
> -- 
> Lars Eggert                                     NEC Network 
> Laboratories
>

---

From: kent at bbn.com (Stephen Kent)
Date: Thu Nov 18 09:45:11 2004

>conflicting with each other.

I agree that if BTNS is going to pursue several non-certificate based 
means of achieving its goals, then pki4ipsec is not the best choice. 
But, if the primary focus is enabling use of self-signed certs with 
IPsec, then pki4ipsec is just the right place. Also, if one wants to 
maximize the likelihood that BTNS functionality will be compatible 
with IPsec, pki4ipsec is an appropriate venue, because of the 
coordination with the IPsec RFC editors and with vendors.  For 
example, we discussed the concerns of how to allow BTNS access and 
authentication access to the same IPsec entity, in a way that does 
not undermine the security of the latter style of access. That 
requires careful coordination with the current IPsec RFCs and is 
consistent with the PAD text I am writing now for pki4ipsec.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu Nov 18 10:09:18 2004

On Thu, Nov 18, 2004 at 12:26:15PM -0500, Stephen Kent wrote:
> IPsec, then pki4ipsec is just the right place.

Exactly.  As I see it BTNS should be a profile of IKE and 2401/2401bis
that allows the use of *non*-pre-shared self-signed certs for
"authenticating" SAs.

This profile will, in many ways, be very similar to work that is ongoing
in the PKI4IPSEC WG, as it relates to ID types and values and policy in
similar ways.

Perhaps we should have a consensus call on this approach to BTNS
_first_.

But I see no other reasonable way to design BTNS -- though I did use to,
as some of you might recall from my presentation on channel bindings at
SAAG at Minneapolis.

(Also, one nice property we get from using non -pre-shared self-signed
certs for BTNS is that it enables leap-of-faith pre-sharing *and*, also,
non-leap-of-faith pre-sharing through the use of authentication at
higher layers with channel bindings to BTNS channels.)

>                                                Also, if one wants to 

Agreed.

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu Nov 18 10:37:11 2004

Nicolas Williams wrote:
| On Thu, Nov 18, 2004 at 12:26:15PM -0500, Stephen Kent wrote:
|
|>At 8:51 AM -0500 11/18/04, <[email-masked]> wrote:
|>
|>>I will second Lars' objection of rolling BTNS work into PKI4IPSEC.
|>>The former is about making things work without PKI, while the latter
|>>is all about facilitating use of PKI specifically for IPsec. I do not
|>>see how we are going to address exactly opposite goals within the
|>>charter of one working group. I do not see how these two different
|>>efforts with different goals are going to come up with proposals
|>>conflicting with each other.
|>>
|>>Atul
|>
|>I agree that if BTNS is going to pursue several non-certificate based
|>means of achieving its goals, then pki4ipsec is not the best choice.
|>But, if the primary focus is enabling use of self-signed certs with
|>IPsec, then pki4ipsec is just the right place.
|
|
| Exactly.  As I see it BTNS should be a profile of IKE and 2401/2401bis
| that allows the use of *non*-pre-shared self-signed certs for
| "authenticating" SAs.
|
| This profile will, in many ways, be very similar to work that is ongoing
| in the PKI4IPSEC WG, as it relates to ID types and values and policy in
| similar ways.

However, PKI4IPSEC is focused on VPN-type solutions; BTNS has a broader
potential community. While the work may be similar in style, they are
different directions.

BTNS is more than just profiling, however. We already noted that there
might be mods needed to the SPD, SAD, etc. to accomodate these new types
of certificates. That's certainly an area of divergence.

Finally, there is the possibility that BTNS will evolve to address
anonymous keying elsewhere, either coordinating with other WGs or
addressing it after rechatering. That would detract from the focus of
PKI4IPSEC.

In summary, these are two different approaches, and combining the
efforts of BTNS and PKI4IPSEC doesn't help either community IMO, and is
likely to be directly counterproductive as well.

Joe

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Thu Nov 18 11:23:11 2004

>>>>> "Joe" == Joe Touch <[email-masked]> writes:

    Joe> Finally, there is the possibility that BTNS will evolve to
    Joe> address anonymous keying elsewhere, either coordinating with
    Joe> other WGs or addressing it after rechatering. That would
    Joe> detract from the focus of PKI4IPSEC.

I know I'm uncomfortable with this evolution within the same working
group.  If anonymous keying is needed for some other technology that
does not support it, we will spin up a working group for that effort
or conduct it in the appropriate existing working group.

    Joe> In summary, these are two different approaches, and combining
    Joe> the efforts of BTNS and PKI4IPSEC doesn't help either
    Joe> community IMO, and is likely to be directly counterproductive
    Joe> as well.

Assuming you're interested in being receptive to comments from the
pki4ipse community, I don't see these efforts conflicting if conducted
in the same working group.  

You're right though that any significant community can make it hard to
build consensus.  What I'm hearing from the existing participants in
the pki4ipse working group suggests they are not trying to block an
anonymous keying effort.  In fact several messages have been quite
supportive of the effort.

Would you mind helping meunderstand why these efforts will conflict?

--Sam

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu Nov 18 11:46:15 2004

> or conduct it in the appropriate existing working group.

I second Sam's point that such non-IPsec related unauthenticated key
exchange proposals could result in a new WG being spun up, or even
placed in some appropriate, existing WG, if feasible.

Remember, at the BoF we reached consensus on pretty much one
non-informational work item: an unauthenticated mode for IPsec,
specifically touching on IKE and the processing model.

No other non-IKE related unauthenticated key exchange proposal were
made.

Also agreed to at the BoF, as I recall, was an informational problem
statement document.  The full/partial hashing / cookie proposal was
dropped until evidence is presented in its favor.

Cheers,

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu Nov 18 11:46:46 2004

Sam Hartman wrote:
|>>>>>"Joe" == Joe Touch <[email-masked]> writes:
|
|
|     Joe> Finally, there is the possibility that BTNS will evolve to
|     Joe> address anonymous keying elsewhere, either coordinating with
|     Joe> other WGs or addressing it after rechatering. That would
|     Joe> detract from the focus of PKI4IPSEC.
|
| I know I'm uncomfortable with this evolution within the same working
| group.  If anonymous keying is needed for some other technology that
| does not support it, we will spin up a working group for that effort
| or conduct it in the appropriate existing working group.

We should talk about this off-line, since it represents a shift from
what was discussed with the previous ADs before this meeting.

|     Joe> In summary, these are two different approaches, and combining
|     Joe> the efforts of BTNS and PKI4IPSEC doesn't help either
|     Joe> community IMO, and is likely to be directly counterproductive
|     Joe> as well.
|
|
| Assuming you're interested in being receptive to comments from the
| pki4ipse community, I don't see these efforts conflicting if conducted
| in the same working group.
|
| You're right though that any significant community can make it hard to
| build consensus.  What I'm hearing from the existing participants in
| the pki4ipse working group suggests they are not trying to block an
| anonymous keying effort.  In fact several messages have been quite
| supportive of the effort.
|
| Would you mind helping meunderstand why these efforts will conflic?

We're not doing a PKI; anonymous keying is PKI-free. Talking about it in
the context of doing PKI is liable to beg the question:
	"if we fix PKI, why do we need anonsec?"

That's not a productive question to ask, since I think the answer is "we
still need it".

Further, the pki4ipsec wg is not focused on IPsec changes (SAD/SPD), and
_is_ focused on VPN, which anonsec is not.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu Nov 18 11:58:11 2004

> 	"if we fix PKI, why do we need anonsec?"

I don't agree.  We already reached consensus on BTNS work at the BoF and
now we're talking about writing into an existing charter (vs. opening a
new WG); that question won't come up (and if it did we've shown we can
answer it).

> _is_ focused on VPN, which anonsec is not.

I don't see the focus on VPNs; VPNs are part of the charter there
though.

Nico
--

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Thu Nov 18 12:18:09 2004

On Thu, 2004-11-18 at 14:22, Sam Hartman wrote:

> Would you mind helping me understand why these efforts will conflict?

I believe that while there is substantial overlap in participants, I
don't think there's really isn't substantial overlap in either charter
or mindset.

pki4ipsec has, so far, largely been constrained as a profiling effort;
I'm not yet convinced that BTNS can really fit there and I'd rather see
a separate working group to keep these mindsets distinct.  (In
particular, I would like to ensure that if the BTNS effort concludes
that a tweak or extension to the architectural model of the IPsec SPD is
required that it's not viewed as out of scope..)

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Thu Nov 18 12:43:12 2004

>>>>> "Joe" == Joe Touch <[email-masked]> writes:

    Joe> We're not doing a PKI; anonymous keying is PKI-free. Talking
    Joe> about it in the context of doing PKI is liable to beg the
    Joe> question: "if we fix PKI, why do we need anonsec?"

    Joe> That's not a productive question to ask, since I think the
    Joe> answer is "we still need it".

Fortunately once a charter has been approved, the question of "why are
we doing this," is out of scope for charter items.  Such questions
should be addressed to the IETF as a whole, the IESG or the IESG and
IAB.  That will be true regardless of what working group work proceeds
in.

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu Nov 18 13:00:44 2004

Nicolas Williams wrote:
| On Thu, Nov 18, 2004 at 02:22:18PM -0500, Sam Hartman wrote:
|
|>>>>>>"Joe" == Joe Touch <[email-masked]> writes:
|>
|>    Joe> Finally, there is the possibility that BTNS will evolve to
|>    Joe> address anonymous keying elsewhere, either coordinating with
|>    Joe> other WGs or addressing it after rechatering. That would
|>    Joe> detract from the focus of PKI4IPSEC.
|>
|>I know I'm uncomfortable with this evolution within the same working
|>group.  If anonymous keying is needed for some other technology that
|>does not support it, we will spin up a working group for that effort
|>or conduct it in the appropriate existing working group.
|
| I second Sam's point that such non-IPsec related unauthenticated key
| exchange proposals could result in a new WG being spun up, or even
| placed in some appropriate, existing WG, if feasible.
|
| Remember, at the BoF we reached consensus on pretty much one
| non-informational work item: an unauthenticated mode for IPsec,
| specifically touching on IKE and the processing model.
|
| No other non-IKE related unauthenticated key exchange proposal were
| made.

The work has always been discussed in the context of a solution that
could apply to various protocols, some of which are in WGs, some of
which are not. It isn't clear that each effort would warrant a new WG.

BTNS could (should) be the place where this work is centered and homed.
WGs focused on a per-protocol basis is a good way to ensure that a
variety of conflicting approaches are developed. The point of having a
single WG was to address the _issue_, not just a specific protocol. The
charter is intended to focus the work on one specific protocol at a time.

| Also agreed to at the BoF, as I recall, was an informational problem
| statement document.  The full/partial hashing / cookie proposal was
| dropped until evidence is presented in its favor.

I said above that this could be about anonymous keying elsewhere, not
about the high-performance variants.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu Nov 18 13:02:14 2004

Sam Hartman wrote:
|>>>>>"Joe" == Joe Touch <[email-masked]> writes:
|
|
|     Joe> We're not doing a PKI; anonymous keying is PKI-free. Talking
|     Joe> about it in the context of doing PKI is liable to beg the
|     Joe> question: "if we fix PKI, why do we need anonsec?"
|
|     Joe> That's not a productive question to ask, since I think the
|     Joe> answer is "we still need it".
|
| Fortunately once a charter has been approved, the question of "why are
| we doing this," is out of scope for charter items.  Such questions
| should be addressed to the IETF as a whole, the IESG or the IESG and
| IAB.  That will be true regardless of what working group work proceeds
| in.

Sure, we can always say "rathole", but we'll be _in_ the rathole saying it.

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Fri Nov 19 07:48:18 2004

Nico,

Other than the newly coined phrase "non -pre-shared self-signed 
certs" I think we are in agreement.  note that EE certs are generally 
NOT pre-shared. there just has to be a trust anchor accessible to 
each peer for use in validating the EE cert send via IKE.  I can see 
why you might want to emphasize the lack of a need to pre-share a TA, 
but the phrase you chose sounds too much like the (pre-) shared 
secret terminology that I think it may confuse folks.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Nov 19 10:21:24 2004

> secret terminology that I think it may confuse folks.

Well, I *had* to coin a phrase :)

But yes, I see your point -- *any* cert will do for unauthenticated
IPsec, whether pre-shared or otherwise, self-signed or signed by a CA
because a peer proposing unauthenticated IPsec will assert only its
cert's public key as an ID.

In practice I see peers using self-signed certs, without pre-sharing
them, to get unauthenticated IPsec.

Suggestions on terminology?

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Nov 19 10:47:23 2004

> cert's public key as an ID.

*Any* cert will do, but still requires a cert.

*No* cert is a lot easier to deploy than *any* cert.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20041119/b631a72a/signature.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Nov 19 10:56:21 2004

> *Any* cert will do, but still requires a cert.

Yes.  But I expect that self-signed certs would be used for this
purpose.

> *No* cert is a lot easier to deploy than *any* cert.

I don't believe this; self-signed certs, particularly when there's no
pre-sharing requirements, are *easy*.

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Fri Nov 19 11:09:20 2004

> *No* cert is a lot easier to deploy than *any* cert.

if you just use a self-signed cert as a way to bind a "hello my name is"
unauthenticated name to a key for an SSH-like leap-of-faith mechanism, I
emphatically disagree.

---

From: kent at bbn.com (Stephen Kent)
Date: Fri Nov 19 14:27:26 2004

At 12:19 PM -0600 11/19/04, Nicolas Williams wrote:
>_______________________________________________

just refer to them as  "self signed" certs and that should suffice. 
since we send the EE cert in IKE when we use certs, there is not a 
need to "pre-share" it.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Nov 19 15:53:20 2004

> just refer to them as  "self signed" certs and that should suffice. 

Unfortunately I've found that when I say "self-signed certs" everyone
assumes a need to securely pre-share them.

> since we send the EE cert in IKE when we use certs, there is not a 

Except that until now there's always been a need to ensure that the peer
knew to trust that cert [for some ID] ahead of time.  Unauthenticated
IPsec would allow the assertion of self-signed cert's public keys
without such pre-sharing.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Mon Nov 22 08:22:38 2004

>assumes a need to securely pre-share them.

It's not literally pre-sharing between the IKE peers; the generic PKI 
requirement is to acquire trust anchors via integrity and 
authenticity secure channels. a self- signed cert addresses some of 
the integrity issues, but still retains the need to authenticate the 
source, and to then impose appropriate controls on the use of TAs 
acquired in this fashion.

>without such pre-sharing.

right.

how about "ecumenical" self-signed certs, -:) to emphasize the 
willingness to accept them from anyone?

Steve