[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CRACK

Dan Harkins writes:
> does not yet formally exist. Please check it out and comment. It's
> called draft-harkins-ipsec-ike-crack-00.txt and can be found with the
> others at http://www.ietf.cnri.reston.va.us/internet-drafts.

Here are my comments.

> 3.1 IKE Challenge/Response Abstract Representation
> ...
>    key respectively, over an authenticating digest.  This digest is the
>    prf output (see [HC98]) using SKEYID_a as a key and a hash (using the
>    negotiated hash function) of all packets sent in the protocol, not
>    including the current exchange, excluding retransmissions, and prior
>    to encryption (or after decryption), when applicable.

It should also state here whether or not the padding added before
encryption is removed before hash calculation or not. The problem of
course is that the received packet length contains the padding, and
finding out the original length without padding requires some work.
To find that out you need to check the payload chain and check how
many extra bytes there are after the final payload.

> 3.2 IKE Challenge/Response Authentication Failures
> ...
>    The Notification Payload MUST have the following format:
> ...
>    with the following "Notification Data":
> 
>      o  LAM Type (two octets) - set to the LAM Type the server requires
>         for the client; MAY be different than the LAM Type specified in
>         any CHRE payloads if the server required a different LAM Type
>         than what was offered
>      o  RESERVED (two octets) - MUST be zero (0) (alignment)
>      o  Status (four octets) - authentication failure status (private to
>         the implementation); SHOULD be omitted when unused

I would suggest format similar that is in the
draft-ietf-ipsec-notifymsg-01.txt instead. I.e use ISAKMP data
attributes inside the notify data, and reserve some new attribute
classes for those new values (LAM type, and status). I am not sure
what the Status is used for, and is it really needed?

Perhaps we should reserve space from the attribute class numbering
space in the notifymsg draft for exchange specific attributes. I.e
those values are defined in the drafts defining the new exchanges. 

> 4.2 LAM Attributes
> ...
>    CRACK_MESSAGE specifies an ASCII string to be displayed to the user
>    upon receipt of the corresponding CHRE payload.  CRACK_MESSAGE is
>    valid for all LAM types.  Upon receipt, the contents of
>    CRACK_MESSAGES SHOULD be displayed to the client user, typically
>    along with the CHRE challenge.

I think the BCP18 (RFC2277) states, that you MUST define charset for
all character data, and you MUST be able to use UTF-8 charset. So I
think it is against that RFC to say that CRACK_MESSAGE is an ASCII
string. Changing it to "ISO-10646 UTF-8 string" should fix this issue.
Also we may want to add "standard" warning about escape/control
characters (from the draft-ietf-secsh-architecture-04.txt):

----------------------------------------------------------------------
When displaying text, such as error or debug messages to the user, the
client software SHOULD replace any control characters (except tab,
carriage return and newline) with safe sequences to avoid attacks by
sending terminal control characters.
----------------------------------------------------------------------

Also another think about the message is the language of the message.
The BCP18 says that "Protocols that transfer text MUST provide for
carrying information about the language of that text."

So I think we need:
----------------------------------------------------------------------
...
CRACK_MESSAGE_LANGUAGE	16388	variable
...
CRACK_MESSAGE_LANGUAGE contains the RFC 1766 language tag of the
language of the CRACK_MESSAGE field. If this attribute is not present
then English is assumed. 
----------------------------------------------------------------------

> 5.1 LAM Profiles: Password
> ...
>    Where the digest that is signed (resulting in SIG2 and SIG3) is:
> 
>    digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr |
>                 KEr | SIG1 | Nr | HDR3 | CHRE1 | PK
>                 [ | HDR4 | SIG2 ]))

I think you should also say here something like this:
----------------------------------------------------------------------
The order of the payloads in the prf is the exactly the same order
they appeared in the packets, and because the order of payloads inside
the isakmp packet is not fixed, the actual prf-calculation may not
match this example above. Also if the exchanges includes any other
payloads (notification, vendor-id, certificate request, certificates
etc) they are also calculated into the prf.
----------------------------------------------------------------------

Also I don't think it is usefull to duplicate the digest calculation
in all examples, I think it is enough to have it only once, and refer
to it later. 

> 5.3 LAM Profiles: Challenge/Response
> ...
>      The CHRE2 payload contains the gateway's challenge
>      text which MUST be displayed to the client user.

I think the MUST there is too strong, now this would rule out all the
systems that process the challenge automatically, because this one
here requires the software to show the text to user :-)

> 7. Security Considerations
> 
>    The channel that results from the exchange of the first two messages
>    is secured because the gateway signs his Diffie-Hellman public value
>    and it is the resulting SKEYID state (see [HC98]) that protects the
>    channel.  The client, though, does not sign his Diffie-Hellman public

I think it is too weak to only sign the Diffie-Hellman public value,
because that does not bind the signature to the current client. This
means that somebody might take the signature, Diffie-Hellman public
key, and start cracking the public key. After he cracks the
Diffie-Hellman public key, he can act as a server for the any new
clients, and the clients will only know that something is wrong when
the server is not able to generate SIG2 later.

This is fixed very easily by saying that the SIG1 is signature of the
hash of the concatenation of the Ni, Nr, KEi and KEr like this:

	hash1 = HASH(Ni | Nr | KEi | KEr)

using the negotiated hash algorithm. This kind of modification would
make sure that the SIG1 is always tied to the current client, and
cannot be reused later.

One big advantage of this draft is that it really fixes that problem
of normal IKE exchanges that generic header and extra payloads are not
authenticated. 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
Follow-Ups: References: