Subject: comments on draft-ietf-ipsra-reqmts-03.txt

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 May 2001 15:02:15 -0700 (PDT)

1. Introduction

This section includes a large discussion relating to L2TP that seems to
interrupt the flow of the document. Since this a requirements document for
IPSRA, I'd suggest that this discussion be translated into requirements,
be moved to an evaluation document comparing alternatives against
requirements, or be taken out of the document altogether. 

In particular, this discussion makes points relating to machine versus
user authentication and the security of RADIUS that are actually quite
general, and not really L2TP related. However, as it stands the points are
not well integrated with the rest of the document. For example, if RADIUS
is so insecure as to be an issue with L2TP, then presumably it should also
not be used in IPSRA to authenticate a temporary cert enrollment, so there
are requirements implications here. Furthermore the
arguments for user versus machine auth would also presumably apply to any
VPN protocol. Both of these points need to be further developed.

Since RADIUS insecurity is referred to, I think a reference is needed
here. This might be to RFC 2607 or 2869 security considerations sections,
but it's hard to tell from the context. If this is really a serious issue
I think that it needs to be documented in detail in the requirements, so
that we can understand how to avoid the concerns in IPSRA. 

2. pp.8. I disagree with the definition of user authentication. Using a
user's identity is not sufficient to truly implement user authentication
within IPSEC. You also need to be able to separate user contexts so that
one user cannot use the IPSEC SA opened under another user context. This
is tricky to say the least, and implies negotiation of specific
non-overlapping selectors. There's a good reason why most IPSEC
implementations don't work this way -- doing this is hard. So I think we
need to be careful to define what is meant here and what we are
recommending that implementations need to do. I'd argue that merely using
a user identity for authentication in IKE doesn't really give you much of
a security advantage over machine auth, particularly if the machine cert
is stored on a smart card.

3. Section 3.3.5 (page 28).

It would appear that this section mandates NAT traversal for IPSRA. Is
this the intent? If so, I think it's a good idea -- this is a real
customer requirement. 

Note however, that if one also mandates true user auth and therefore
specific selectors, then IPSEC tunnel won't meet the requirements without
changes.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 14 May 2001 19:24:19 -0700

Hi Bernard,

Thanks for taking the time to review the draft in detail. Comments
interspersed below...

> requirements, or be taken out of the document altogether.

I agree. The original intent was to explain the motivation for looking
at mechanisms other than l2tp, but I think you are right: this doesn't
belong in the requirements document. It will be removed, unless someone
else argues persuasively to the contrary.

> that we can understand how to avoid the concerns in IPSRA.

Again, no argument. I think the appropriate thing to do is make some
comment in the security considerations about radius. I think the user vs
machine considerations are discussed elsewhere within the doc, and I'll
check to see if we need to integrate anything from the l2tp discussion
into that discussion.

> is stored on a smart card.

I'm not sure I understand what you mean by "separate user contexts".
Please explain what your concerns are in more detail. The system I work
on is capable of negotiating non-overlapping selectors, and
authenticating these on a per-user basis. I also know of at least one
commercial multi-user OS which is also capable of isolating SAs to the
appropriate users and selectors.

Regarding user auth vs machine auth, the relative strength of each
depend upon how securely the private key is stored, and on other factors
which are discussed in the draft. Using a user identity in conjunction
with a short-lived private key narrows the exposure significantly when
compared to using a private key that sits on the hard drive of a
relatively open commercial operating system for who knows how long. This
is a point well worth mentioning.

> this the intent? If so, I think it's a good idea -- this is a real

I didn't intend to say it is a hard requirement for remote access. I
think the doc says napt traversal is required *if* the implementation
must operate in a napt environment. This is by no means always the case,
though I agree that there are way more napt devices out there than there
used to be.
 
> specific selectors, then IPSEC tunnel won't meet the requirements without

You lost me - please elaborate.

Thanks,

Scott