Subject: RE: evaluation draft

From: "Mason, David" <[email-masked]>
Date: Mon, 9 Jul 2001 12:45:26 -0700

Someone has already pointed out that PIC is basically the same as Hybrid
(minus the ability to do a Quick Mode) so I think most of the arguments
about which is better seems like a lot of hot air.  

Some of my hot air:

The big advantage to PIC is that hopefully the PKI vendors will enable it to
issue long term credentials in an automated fashion thereby alleviating the
logistic headache of initial certificate deployment to a large user base.
The use of EAP is a nice touch.

Since two-factor requirements will exist even after a fully deployed PKI is
available, security gateways will likely provide that support to avoid
requiring the customer to have a separate AS.  A security gateway that has
to provide Legacy Auth support (act as the AS) will likely prefer Hybrid
(not much reason to duplicate all that code, avoids public/private key pair
generation the results of which will be thrown away shortly, avoids extra
communication rounds).  The users of palm devices will prefer Hybrid since
the device will only have to do one public key verification (I'm afraid PIC
followed by IKE Signature will be painfully slow on a palm device).

-dave

---

From: Tylor Allison <[email-masked]>
Date: Mon, 9 Jul 2001 16:43:35 -0500 (CDT)

Hi Scott,

I've read through the draft and have some comments.  I'll try to be as
objective as I can, but I'll state up front that I strongly believe that
PIC/GetCert are the wrong solution to the Legacy Remote Access problem.
To know where I am coming from... We have implemented/fielded XAUTH.
Is this the best solution?  Maybe not, but it was the best fit at the time.

The biggest problem I have with PIC/GetCert is that they don't provide the
most straight-forward solution to the Legacy Remote Access problem.  To
reiterate your definition of the problem: Customers want to use legacy
authentication mechanisms with the IPSec deployments.  Now how does IPSec
currently handle remote peer authentication?  IKE.  But as you state, IKE
currently only supports symmetric authentication mechanisms, and this does
not fit wth the legacy authentication methods.  The simplest most
straight-forward solution then?  Fix IKE to support the legacy
authentication mechanisms, not try to work around the current IKE
limitations by defining new protocols to bootstrap IKE.  Yes this means
modifying IKE and yes this means adding more complexity to IKE.

I'll try to provide some more detailed arguments in response to your draft
in my comments interspersed below...

On Thu, 5 Jul 2001, Scott G. Kelly wrote:

> 5.1 XAUTH/MODECFG
[TA]
       Summarized other XAUTH concerns...
       o Xauth leverages existing IKE phase 1 exchange and is susceptable
         to current IKE phase 1 attacks.   True, global pre-shared keys
	 with XAUTH introduces some security concerns.

>      o Xauth requires the SGW to participate in the user authentication
>        process, which increases SGW vulnerability both in terms of
>        complexity and denial of service.
[TA]
I don't believe this matters... the complexity issue exists for all
solutions (see below), and I don't believe the DoS attack is any worse than
what currently exists (again, see reasoning below).

>      o Adding an open-ended number of challenge-rsp exchanges to a key
>        exchange increases vulnerability to denial of service attack
>        under some circumstances, and absolutely increases the complexity
>        of the key exchange mechanism under all circumstances. While an
>        open-ended exchange may not be entirely avoidable given the
>        n-factor authentication requirement, xauth does not begin such
>        exchanges until a phase 1 IKE SA has been instantiated, and this
>        with either limited or no knowledge of the user identity in
>        several of the supported configurations. The overhead associated
>        with the DH exchange is significant, and the fact that an
>        anonymous peer may force expenditure of this effort implies that
>        a system supporting the associated configuration is trivially
>        susceptible to denial of service. Further, once such phase 1
>        sessions are established, the SGW may be "led on" by a malicious
>        peer for some (hopefully limited) period of time, guaranteeing
>        that the associated system resources will remain unavailable
>        during this period.
[TA]
Same argument which I'll defer to below.

>      o Xauth requires proxy support in the SGW for up to 16 different
>        authentication methods, which greatly increases system
>        complexity.

>      o There may be some known ascii plaintext at fixed locations within
>        packets due to support for user prompts. The amount of text will
>        normally be small, but should not be ignored. If a reusable
>        passphrase is contained within the xauth exchange, an attacker
>        may have significant motivation for breaking the IKE session
>        encryption, and known plaintext will simplify this task.
[TA] - already discussed to death...

>      o Xauth requires support for its companion, modecfg. This
>        duplicates some of the functionality of DHCP, but lacks support
>        for critical components, implying that it is redundant, and
>        therefore adds unnecessary complexity. However, one has no choice
>        but to implement modecfg if one wishes to implement xauth.
[TA]
This is not true.  XAUTH and Mode-Config are two exchanges which share
the same payloads and exchange number.  One does not have to implement
mode-config functionality to implement XAUTH.

> 5.2 Hybrid
[TA] - summarized...
       o susceptable to DoS attacks because of one-way authentication of
         phase 1 SA (prior to legacy exchange).
       o phase 1 exchange is left in "limbo" until legacy exchange is
         completed.
       o other vulnerabilities similar to XAUTH exchange.
[TA] - very similar to XAUTH... see below for my overal DoS arguments.

> 5.4 CRACK
>    o IRAS must produce signature prior to authenticating user
>    o IRAS must complete DH computation to detect spurious second
>      message from attacker
>    o IRAS must participate in the legacy user authentication process
>    o requires support for an additional IKE exchange type

> 5.6 PIC
>      o if PIC is run on the sgw, the sgw is subject to DoS attacks due
>        the fact that it must generate a signature and compute a DH
>        exponential prior to authenticating the remote access user.
[TA]
These are the same DoS concerns that you have for the above protocols.

>      o separate connections are required for authentication and access;
>        however, this implementation detail may be rendered transparent
>        to the user
[TA]
This will have to be configured somewhere, right?  So someone will have to
set it (whether it is the end-user or an administrator).  Instead of
having the possibility for a single authentication exchange failure, you
now have to concerned with two separate auth exchange failures.  From a
customer support perspective, this added complexity sounds like a
nightmare.

[TA]
       o greater overall complexity
	 The implementation of a separate protocol services by separate
	 components on separate hardware, and the interaction between these
	 new components and the existing IPsec architecture make this
	 choice more complex.  Added complexity leads to added security
	 concerns.

> 5.7 GetCert
>
>    Security issues with this method include the following:
>
>      o if GetCert is run on the IRAS, the IRAS is subject to DoS attacks
>        due the fact that it must field incoming SSL connections from
>        unauthenticated users
>
>      o separate connections are required for authentication and access;
>        however, this implementation detail may be rendered transparent
>        to the user.
[TA]
       o greater overall complexity
	 The implementation of a separate protocol services by separate
	 components on separate hardware, and the interaction between these
	 new components and the existing IPsec architecture make this
	 choice more complex.  Added complexity leads to added security
	 concerns.

>    6.4 User authentication information must be protected against
>    eavesdropping and replay (including the user identity)
>
>    Proposals requiring the use of aggressive mode do not meet this goal,
>    meaning the preshared key modes of XAUTH, ULA, and L2TP. It might be
>    argued that these mechanisms may use preshared keys with fixed IP
>    addresses (and hence use main mode), but this raises obvious SGW
>    scaling issues, and therefore these cases do not represent likely
>    remote access scenarios. Hence, XAUTH, ULA, and L2TP only meet this
>    goal when used with IKE main mode and public keys. All other
>    proposals meet this goal unconditionally.
[TA]
Even with a known preshared key, an attacker would still need to break the
DH exponentiation to eavesdrop... correct?

>    6.5 Single sign-on capability should be provided in configurations
>    employing load-balancing and/or redundancy
>
>    Only proposals which permit the user to instantiate a connection with
>    a redundant IRAS without re-entering user authentication information
>    (username, password, etc) meet this goal, i.e.  PIC and GetCert.
[TA]
I don't see how single-sign on works for the GetCert/PIC method.  This is a
difficult problem that I feel is not adequately addressed by any solution
I've seen to date.

>    6.7 Security gateway vulnerability to DoS attacks should be
>        minimized, and if possible, should not be greater than the
>        vulnerability which exists in SGW systems not providing remote
>        access.
>
>    Proposals requiring no modification to the underlying IPsec
>    implementation unconditionally meet this goal. The only proposals
>    having this characteristic are PIC and GetCert, when they are run on
>    outboard authentication servers. Proposals requiring modification to
>    the underlying IPsec implementation must be examined more closely.
[TA]
I don't agree with this logic.  You need to consider what it means to
add a remote access capability to a base IPsec system, even if you don't
change the code.  Ultimately, with any solution, you are allowing an
unknown entity to connect to your SGW instead of just individual hosts.
The implications of this is that you have opened yourself up to DoS attacks
inherit to IKE.  To say that PIC and GetCert are immune, or better than the
other approaches is a misrepresentation (atleast for some of the other
protocols).  More to come...

>    All members of the class of proposals which defer user authentication
>    until after a phase 1 SA has been negotiated (XAUTH, HYBRID, ULA,
>    L2TP) are more vulnerable to DoS attacks than those not sharing this
>    characteristic. CRACK, while not strictly in this class (it
>    authenticates the user *during* phase one), must also be considered
>    with this group due to other similarities. Of these proposals, HYBRID
>    and CRACK are clearly the most vulnerable, since they require the SGW
>    to perform Diffie-Hellman and public key computations for an
>    unauthenticated peer.
[TA]
DH exponentiation can be exploited for all methods.
This is true of all methods because this vulnerability lies within IKE.

>    6.8 The chosen mechanism(s) should minimize any reduction in the
>        baseline security of the underlying IPsec connection
[TA]
Shouldn't the goal be to minimize any reduction of the security of the
system including the remote access solution?

>    Proposals requiring no modification to the underlying IPsec
>    implementation clearly meet this goal. The only proposals having this
>    characteristic are PIC and GetCert (when implemented on outboard
>    authentication servers). Proposals requiring modification to the
>    underlying IPsec implementation must be examined more closely.
>
>    All proposals other than PIC and GetCert modify the underlying IPsec
>    implementation, and so introduce some probability that the security
>    of the underlying implementation (and therefore, that of the
>    connection) has been reduced. The XAUTH, HYBRID, and CRACK approaches
>    all directly modify IKE by adding new states and protocol elements.
>    This certainly increases code complexity, along with the probability
>    of an implementation error. However, this effect is most difficult to
>    quantify.
>
>    In addition, all approaches other than PIC and GetCert (and perhaps
>    L2TP) require the SGW to act as a proxy in the user authentication
>    protocol. L2TP may avoid this by terminating the L2TP tunnel on a
>    host behind the SGW rather than on the SGW itself, but if this is
>    done, then there must also be some protocol between the L2TP
>    termination point and the SGW which permits access revocation if the
>    user fails to properly authenticate - otherwise, the L2TP server may
>    terminate the connection, but the SGW won't know it - which again
>    adds complexity to the SGW.
[TA]
PIC and GetCert may use a separate server, but the still need to proxy the
same requests to a third-party authentication server, right?  I'm not sure
what offloading this to a separate server buys you, besides added
complexity.

> 7. Summary
>
>    The various proposals come out on fairly equal footing regarding
>    several of the stated requirements, with differences emerging in the
>    following 3 areas:
>
>      o increased SGW susceptibility to DoS attacks
>
>      o increased SGW complexity
>
>      o single sign-on support
>
>    These are discussed in more detail below.
>
> 7.1 DoS Susceptibility
>
>    XAUTH, HYBRID, ULA, CRACK, and L2TP are all susceptible to DoS
>    attacks under some circumstances.  HYBRID and CRACK are trivially
>    susceptible to DoS attacks. PIC and GetCert only increase the SGW's
>    DoS susceptibility if they are implemented on the SGW. L2TP, ULA, and
>    XAUTH are less susceptible than HYBRID and CRACK if the remote user's
>    private key is securely contained, but only in this case. To the
>    extent that the private key is susceptible to compromise, the DoS
>    risk increases proportionally. As noted earlier, a private key stored
>    on the hard drive of a typical user system would not stand up to a
>    determined adversary.
[TA]
My DoS conclusions don't match with what you have stated...
XAUTH
    The DoS attacks against XAUTH are similar to native IKE, since XAUTH
    is an extension of phase 1 exchange.  I don't believe that the
    knowledge of a preshared key helps a DoS attacker to any great extent,
    as they would have to work harder (more cycles) at a DoS attack in
    order to use it.
Hybrid
    Again similar to native IKE, you have to have an active DoS attacker
    sending and receiving packets.  Making the SGW compute values for
    complete phase 1 exchange is not much different from just computing DH
    exponentiation and it comes at the expense of the DoS attacker having
    to perform the DH operations.
CRACK
    As currently documented, CRACK is susceptable to non-active DoS
    attacks... meaning that a DoS attacker can forge bogus packets and force
    the SGW to perform DH exp.  This could be remedied by modifying the
    protocol to perform two round trips before full exponentiation.  This
    would force an active DoS attack to exploit the DH exp and then would
    be similar to current IKE.
PIC/GetCert
    You have taken the stance that offloading the User Auth to a separate
    box will reduce DoS possibilities, and therefore PIC/GetCert is
    better.  If you look only at the SGW, I'll grant that the DoS attack
    against PIC/GetCert is less than if PIC/GetCert are implemented on the
    SGW.  I know that there is a strong reason why we want to reduce the
    risk of DoS attacks on the SGW.  But we must also look at the DoS
    attacks that can be waged against the protocol that you are
    promoting.  PIC/GetCert are no better and sometimes worse than many
    of the other proposals.  You have all the DoS vulnerabilities of IKE,
    coupled with DoS vulnerabilities introduced by the new protocol.  In
    this regard, PIC is as bad as you make out CRACK to be(I'm not sure
    where GetCert fits).  Look at the protocols... they are almost the same!
    Plus, you have given the attacker two points to compromise... I'll get
    into this more in a bit.

>    While it may be argued that using a smartcard (or other secure
>    container) goes a long way toward resolving this problem, it must be
>    noted that this imposes a significant increase in the cost of the
>    solution, both economically and logistically. In this case,
>    smartcards (or whatever security container is used) must be provided
>    for each remote access user, and these must be managed. And if one is
>    stolen, it may be used for DoS attacks (or worse, unfettered access)
>    until it is discovered missing.
>
>    An alternative to secure containers is to provide a short-lived key
>    at the time access is desired which is good for a limited time only.
>    The short lifetime of the key significantly narrows the window during
>    which it might be compromised, and if such a key were somehow
>    compromised, the damage potential would be bounded by its lifetime.
>    That is, if the key lifetime is sufficiently short, the only
>    realistic compromise scenario (for DoS purposes) entails gaining
>    control of the system while the key is valid and passing it along to
>    the attacker. However, an attacker with this capability can also gain
>    control of a system relying on a smartcard, and by proxy, full access
>    to the network beyond the SGW - so the smartcard is not much help in
>    this case, and in such a case, DoS attacks should be the least of our
>    concerns.
[TA]
I believe this is a separate issue than DoS.  It is a security issue of the
protocols in question.  Private Key compromise, Man-in-the-Middle, and
Replay vulnerabilities should be listed separately.

> 7.2 Code Complexity
>
>    XAUTH, HYBRID, ULA, CRACK, and L2TP all significantly increase the
>    complexity of the IRAS code base, while PIC and GetCert need not be
>    implemented on the IRAS.
[TA]
I believe that where the PIC/GetCert code is implemented is irrelevant.
You have to look at the complexity as it applies to the entire Remote
Access sub-system.

To be fair, you must have an apples to apples comparison of the complexity
of the entire Remote Access solution, not just how each solution impacts
IKE.  With this in mind, can you honestly say that you believe the
GetCert/PIC solution is less complex then modifying IKE with one of
XAUTH/CRACK/HYBRID?  But what about modularity of design you might ask?
Modularity can be achieved in many ways... the design however should fit
with the problem you are trying to solve.  Again, the problem is to use
legacy authentication in the IPSec environment.  I contend that a separate
module in an IKE implementation to handle a legacy authentication exchange
is much more inline with the problem, then a module which provides for
certificate retrieval mechanism.

> 7.3 Single Sign-on Support
>
>    XAUTH, HYBRID, ULA, CRACK, and L2TP do not provide for single sign-on
>    support, while GetCert and PIC do (the short-lived certificate may be
>    used to connect to a redundant IRAS).

[TA]
You're assuming that the single sign-on environment is PKI based.  If,
however the single sign-on environment is legacy auth based (e.g. tokens),
the PIC/GetCert methods would not meet this goal.  A separate issue
for all Remote Access solutions is how the user authentication info is
shared in a single sign-on environment.

> 7.4 Conclusion
>
>    The only proposals which meet all criteria are GetCert and PIC (when
>    implemented on an outboard authentication server).
>

My conclusions?  You contend that because PIC/GetCert can offload the Legacy
Auth to a separate box, that this makes these proposals the better choice.
The point I am trying to make, is that while this can offload some of the
DoS and Security concerns from the SGW, you should still look at the entire
Remote Access solution and perform the same analysis.  What are my DoS
concerns?  What are my security concerns?

From a DoS perspective, I would say it is a wash... each proposal has DoS
concerns which need to fully evaluated.  One concern with separate
components... if IKE is fixed to address DoS concerns?  Where does that
leave a separate protocol?

From a security perspective, I believe that the PIC/GetCert solution is not
as secure.  My reasoning?  The complexity issue is definately on the
forefront.  As you have stated, complexity and how it affects security is
very hard to quantify.  Comparing a XAUTH/HYBRID/CRACK solution to the
PIC/GetCert, I hope you can agree that PIC/GetCert is more complex.  Also,
having separate boxes increases the likelihood of other security issues:
e.g. platform/os dependant bugs.

Finally from a design perspective, I have to go back to the original
question.  How can we provide Legacy Authentication to IPsec applications
in a remote access scenario?  What is the simplest way?  I have to believe
this is through fixing the component currently responsible for IPsec remote
party authentication.  Fix IKE.  I honestly believe that if the
requirement to not modify IKE was not in the IPSRA charter, we would have
agreed an a protocol similar to CRACK/XAUTH/HYBRID a long time ago.  But,
it's in the charter?  Fix the charter.  Do what makes the most sense.

Way more than my $.02 I'm sure.

---
Tylor Allison         [email-masked]
Secure Computing Corporation

---

From: "Mason, David" <[email-masked]>
Date: Tue, 10 Jul 2001 12:32:24 -0700

This must be why the NAT-traversal IDs weren't submitted under the IPSRA WG
even though they are a direct requirement (sections 2.5, 3.2.5, 3.3.5,
3.4.5, 3.6.5, 4 of IPSRA requirements ID).

Can someone in charge please explain the criteria of why it's ok to change
IKE/IPsec for some new features and not others?

-dave

-----Original Message-----
From: Paul Hoffman / VPNC [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 2:30 PM
To: Hugo Krawczyk; ietf-ipsra
Subject: Re: evaluation draft

At 8:56 PM +0300 7/10/01, Hugo Krawczyk wrote:
>Personally, I have no problem with those that want to change the charter
>(I wouldn't be against, except that convergence in this case seems 
>impossible).

Any discussion of the charter is out of scope.

Scott pointed out in an earlier message that we are all intelligent 
adults. Why, then, do many of us keep forgetting what has happened in 
the recent past? We have been told repeatedly that the protocol that 
comes from the WG may not change IKE. Many of us have replied "but we 
think that a change to IKE is a better solution". The response from 
the Area Directors has been unequivocal: no changing IKE, no changing 
the charter.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Horn, Mike" <[email-masked]>
Date: Tue, 10 Jul 2001 16:15:43 -0600

I think a few things are missing in the XAUTH section (5.1):

1) XAUTH/MODECFG has been widely implemented and has undergone several
iterations of interoperability testing.  The last count I saw had 17 vendors
claiming some form of XAUTH support.  I think this is a key differentiator
over other proposed solutions.

2) While XAUTH does share many of the inherent vulnerabilities of preshared
keys, it does not appear to weaken the security of the underlying IPsec.  I
agree that it is more vulnerable to DoS if the preshared key is not
appropriately protected.

3) Since XAUTH uses an established IKE SA, some other method less
complicated than MODECFG might be able to be used to pass the username and
passphrase to the SGW.  Depending on the solution, this might help get
around the "no changes to IKE" requirement.

4) XAUTH requires support for 16 different authentication methods increasing
the complexity.  If XAUTH was selected for the standards track, I'm sure
that some (if not most) of the authentication methods could be changed to
optional.

It's not that I biased towards XAUTH for technical reasons, but I'm
concerned that it is here to stay anyway (since it has been so widely
deployed).  I would rather see improvements made to existing technology
(XAUTH) than watch the working group try to figure out what technology it
MIGHT develop.  I would argue that most of the developers on this list are
already intimately familiar with XAUTH and might even have some suggestions
for how to make it better.

Mike Horn

> From: Scott G. Kelly [mailto:[email-masked]]
> Sent: Thursday, July 05, 2001 6:14 PM
> To: [email-masked]
> Subject: evaluation draft
> 
> 
> Hi All,
> 
> Attached is a copy of the draft which compares pic, getcert, 
> crack, ula,
> hybrid, and xauth that I promised months ago. I've submitted it to the
> ID editor (as a personal submission), but also wanted to 
> archive it here
> in the mailing list. I vastly underestimated the amount of work
> involved, and feel as though I'd like to work on it for 
> another week or
> so even now. On the other hand, we need to move forward, so 
> I'm putting
> it out now in order to solicit comments.
> 
> Scott
> 
>