Re: User-level Authentication Mechanisms for IPsec

["Scott G. Kelly" <skelly@xxxxxxxxxxxx>]

Hi Roy,

Roy Pereira wrote:
> 
> Scott,
> 
> >                          <-- REQUEST(TYPE=GENERIC NAME=""
> >                                      PASSWORD="")
> >      REPLY(TYPE=GENERIC NAME="joe"
> >                PASSWORD="foobar") -->
> >                          <-- REQUEST(TYPE=GENERIC
> >                                      MESSAGE="Enter your password
> >                                      followed by your pin number"
> >                                      NAME="" PASSWORD="")
> > Look at all the ASCII TEXT here. As you know, this is all included in
> > the exchange, and in a very predictable location within the packet.
> 
> XAUTH, nor IKECFG stipulates the order of attributes, nor the specific
> contents of them.  The message text can be anything and even empty.
> Thus I don't think that known plaintext is an issue.  The REQUEST/REPLY
> IDs do have to be there, but that is only one byte.
> 

The upper case portions of these messages must be specified. If you
don't specify what is in the message, how can you hope to interoperate
with others? These constitute significantly more known plaintext than is
an any of the other proposals. As I said to Tamir yesterday, this is not
a show stopper taken on it's own, but it certainly adds fuel to the
fire.

> IKECFG doesn't try and replace DHCP or any other configuration
> protocol.  It is required to mainly bootstrap the VPN client with
> essential information.  The draft states this.  The type of information
> being exchanged is crucial to the client before a phase 2 SA is set up,
> and thus this is why IKECFG is at phase 1.5.

Here are the attributes in the current rev if the isacfg draft:

    Attribute                 Value   Type       Length
   ========================= ======= ========== =====================
    RESERVED                    0
    INTERNAL_IP4_ADDRESS        1     Variable   0 or 4 octets
    INTERNAL_IP4_NETMASK        2     Variable   0 or 4 octets
    INTERNAL_IP4_DNS            3     Variable   0 or 4 octets
    INTERNAL_IP4_NBNS           4     Variable   0 or 4 octets
    INTERNAL_ADDRESS_EXPIRY     5     Variable   0 or 4 octets
    INTERNAL_IP4_DHCP           6     Variable   0 or 4 octets
    APPLICATION_VERSION         7     Variable   0 or more
    INTERNAL_IP6_ADDRESS        8     Variable   0 or 16 octets
    INTERNAL_IP6_NETMASK        9     Variable   0 or 16 octets
    INTERNAL_IP6_DNS           10     Variable   0 or 16 octets
    INTERNAL_IP6_NBNS          11     Variable   0 or 16 octets
    INTERNAL_IP6_DHCP          12     Variable   0 or 16 octets
    INTERNAL_IP4_SUBNET        13     Variable   0 or 4 octets
    SUPPORTED_ATTRIBUTES       14     Variable   0 or multiples of 2
    Reserved for future use    15-16383
    Reserved for private use   16384-32767

It is beginning to look curiously like dhcp to me. The config
requirements for remote access clients have already been explored in
depth by the mobile ip and various ppp extension groups. They have
demonstrated that in the end, far more config than the above will be
required. You seem content to ignore this.

> IKECFG and XAUTH are not joined at the hip.  XAUTH does use the same
> mechanisms that IKECFG uses, but this just makes it easier to
> implement.  You don't have to use IKECFG is you only need XAUTH.

>From xauth:

   Readers are advised to be familiar with both [IKE] and [ISAKMP] as
   well as [IKECFG] since this document is an extension to that
   document.

I'd say this pretty well cements their relationship.

>  Please
> remember that these protocols have been published for well over a year
> now and have gone through many revisions because of discussion on the
> mailing lists. 

No, they have not gone through very much discussion yet. People have
been far too busy to give this matter the attention it has now finally
drawn. I don't think it's appropriate to use this fact to justify the
continued use of this flawed approach.

> Having XAUTH use the existing mechanisms in IKECFG was
> deamed better than building yet another protocol.  IKE provides a great
> base that is secure and flexible enough to support extensions.

Yes, so why don't we just forget this ipsec nonsense, and just run IP
over IKE? We can call it "GODZILLAKMP".

> Again, this draft has been around for a long time and has been discussed
> by people who have been interested in IPSec remote acccess.  Just
> because the core IPSec specification is now done and everyone now has
> more time to look at other requirements doesn't mean that some people
> havent been looking at this for awhile now.  There are many released
> products that use these protocols and I haven't heard of any limitations
> within them that prevented the products from solving the customer's
> problems.

These drafts suggest hacking security protocols in order to sell into
the vpn market. Just because you've found others willing to eat part of
that pie doesn't make this appropriate. You know as well as I do that
these products, as currently deployed, represent a significant security
threat to many of your customers' networks. Group preshared keys are not
secure. If these people don't really care about security, that is their
prerogative; however, selling them products which claim be security
devices implementing secure protocols for this usage is deception at
best.
 
> > Rather, it says they add unecessary complexity to the key exchange.
> 
> I know of more than half-a-dozen vendors who have implemented either
> XAUTH and/or IKECFG and complexity wasn't mentioned.  Besides, they
> actually don't add complexity to the "Key exchange".  In fact they were
> designed to not touch the "key exchange".  They are a separate exchange,
> thus the main/aggressive modes that we all use are not touched. (Except
> Hybrid-XAUTH that does alter the phase 1 mode)

If complexity wasn't mentioned, I guess that would be because they
haven't given this due consideration from a security perspective. Let me
reiterate that I'm not saying that implementing this is complex -
analyzing it is. The key exchange PROCESS is *critical* to the resultant
session security. Adding steps OF ANY SORT to this process increases its
complexity. Increasing its complexity makes it more difficult to
provably assert that it is secure. 

> When I speak to customers they want these protocols.  Some want to use
> only their SecurID cards and no certificates, while others want to use
> mutual certification authentication plus SecurID cards.  We must be able
> to solve their problems.

Yes, if you want to sell them products, you must find a solution.
However, this is not justification for hacking security protocols, and
in any event, such hacks should certainly not be standardized by
SECURITY working groups. If the customers really don't care about
security, maybe they should be buying other ppp-based vpn solutions.

> But let me state again, that the actual protocol isn't the important
> piece here and I'm happy to see a lot of people understanding the
> requirements that we are here to solve.  Our protocol(s) must be secure,
> but they also have to allow the marketplace to do what they want and
> like a few people have stated those requirements can range from no
> certificates with legacy authentication to mutual certificates with
> legacy authentication.  Our goal is to find something that solves that
> problem.

That's the bottom line, except that it doesn't recognize that this is an
attempt to solve this problem within a security context. If you don't
care about a security, form a working group outside of the security
area, and hack away to your heart's content.

Scott