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

Re: new AH spec



I guess someone has to toss out the first feedback.

>                         IP Authentication Header
<SNIP!>

> 1. Introduction
<SNIP!>

Looks good so far.  The bit about "piecemeal" might be a bit strong, but
that's really hairsplitting.

> 2.  Authentication Header Format
<SNIP!>

>    *** Do we want to retain a null authentication algorithm as part of the
>    *** spec at this point? What purpose does it serve?

Mostly, the NULL authentication algorithm is used for testing of protocol
plumbing.  I don't expect any shipping product to have a null authentication
algorithm.  I do expect AH implementations that are in their nascent stages
to have a null authentication algorithm.  Interpret this data as you will
w.r.t. how the spec should read.

> 2.4 Security Parameters Index (SPI)
<SNIP!>

>    A value of zero indicates that no Security Association exists.  The SPI
>    field is mandatory.  It is ordinarily selected by the destination
>    system upon establishment of an SA (see "Security Architecture for
>    the Internet Protocol" [KA97a] for more details).
>
>    *** Under what circumstances will a zero SPI be employed?  Is this
>    *** still relevant or is it vestigial?

A zero SPI is useful for any number of implementation-specific aids.  An
example I can think of off the top of my head is that if my
getassocybyendpoint() call for an outgoing datagram returns an association
with a zero SPI, I can interpret this as any number of results (including, "I
just kicked key management in the rear, I'll get back to you.")

> 2.5 Sequence Number
> 
>    This unsigned 32-bit field contains a monotonically increasing
>    counter value (sequence number).  The counter is initialized to 1
>    when an SA is established.  The sequence number must never be allowed
>    to cycle; thus, it MUST be reset (by establishing a new SA and thus a
>    new key) prior to the transmission of 2^32-1 packets on an SA.  The
>    Sequence Number field is optional.  It is included only if the anti-
>    replay service (a form of loose sequence integrity) is selected as a
>    security service for the SA.

I know certain people who have issues about having this field NOT being
present.  I don't have a problem with this, but I suspect the people who have
these issues will speak up.

See the newly issued HMAC-96 drafts for details.

> 3. Authentication Header Processing
> 
> 3.1 Authentication Header Location
> 
>    Like ESP, AH may be employed in two ways: transport mode or tunnel
>    mode.  The former mode is applicable only to host implementations and
>    provides protection for upper layer protocols, in addition to
>    selected IP header fields.  In this mode, AH is inserted after the IP
>    header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc.

BTW, ESP is one of these upper-layer protocol fields.  In fact, lemme return
to this upper-layer protocol idea in a bit.

<SNIP!>

>    In the IPv6 context, AH is viewed as an end-to-end payload, and thus
>    should appear after hop-by-hop, routing, and fragmentation extension
>    headers.  The destination options extension header(s) could appear
>    either before or after the AH header depending on the semantics
>    desired.  The following diagram illustrates AH transport mode
>    positioning for a typical IPv6 packet.
> 
>                        BEFORE APPLYING AH
>             ---------------------------------------
>       IPv6  |             | ext hdrs |     |      |
>             | orig IP hdr |if present| TCP | Data |
>             ---------------------------------------
> 
>                                AFTER APPLYING AH
>             ------------------------------------------------------------
>       IPv6  |             |hxh,rtg,frag| dest |    | dest |     |      |
>             |orig IP hdr  |if present**| opt* | AH | opt* | TCP | Data |
>             ------------------------------------------------------------
>             |<-------------------- authenticated --------------------->|
>                              except for mutable fields
> 
>                 * = if present, could be before AH, after AH, or both
>                ** = hop by hop, routing, fragmentation headers

This isn't _quite_ accurate.

Destination options CAN appear before or after AH.  But the semantic of
destination options is very precise.  From RFC 1883...

	IPv6 | Hop-by-Hop | Destination | Routing | Fragment....

If Destination options appear before AH, they appear before the routing
header.  The semantics being that the destination options are parsed on each
hop specified in the routing header.  This might be hairsplitting, but others
who are IPv6/IPsec implementors might get confused.

<SNIP!>

>    The position of AH in tunnel mode, relative to the outer IP
>    header, is the same as for AH in transport mode.

This sentence is more important than is apparent at first.  An implementation
can look at the inner IP header as JUST ANOTHER UPPER LAYER.  This helps
reduce some of the special-casing for IP as the inner payload.  It doesn't
_ELIMINATE_ it, but it can reduce it.

(For example, if you have A->B with the inner IP saying A->B, you can make
stronger assertions than if the inner packet says something else.)

<SNIP!>

> 3.2  Outbound Packet Processing
> 
>    In transport mode, the transmitter inserts the AH header after the IP
>    header and before an upper layer protocol header, as described above.
>    In tunnel mode, the outer and inner IP header/extensions can be
>    inter-related in a variety of ways.  The construction of the outer IP
>    header/extensions during the encapsulation process is described in
>    the document, "Security Architecture for the Internet Protocol".
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Hmmm.  I'm looking forward to this.

> 3.2.1  Security Association Lookup
> 
>    AH is applied to an outbound packet only after an IPsec
>    implementation determines that the packet is associated with an SA
>    that calls for AH processing.  The process of determining what, if
>    any, IPsec processing is applied to outbound traffic is described in
>    the document, "Security Architecture for the Internet Protocol".

Once again, I'm looking forward to this.

As an aside, I'd strongly encourage to look at the current implementations
out there, as well as some of the analysis literature.  I suspect you've
already done your homework on this front and will be drawing on their
experience when you finish rewhacking the architecture document.

> 3.2.2  Sequence Number Field
> 
>    If the anti-replay service has been selected for this SA, the
>    transmitter increments the sequence number for this SA, checks to
>    ensure that the counter has not cycled, and inserts the new value
>    into the Sequence Number Field.  A transmitter MUST not send a packet
>    on an SA if doing so would cause the sequence number to cycle.

Do you have any recommendations for when the sequence number cycles?  (Kick
key mgmt. in the pants, logging, tuning future SAs to expire sooner, etc.)

> 3.2.3  Integrity Check Value Calculation
> 
> 3.2.3.1  Handling Mutable Fields

<SNIP!>

> 3.2.3.1.1  ICV Computation for IPv4

>    *** What about OFFSET and FLAGS.  Since reassembly takes place before
>    *** AH processing why are these fields omitted from the ICV
>    *** computation?

Except for perhaps DF, these FLAGS and OFFSET SHOULD be zero anyway after
reassembly!  The question of DF is perhaps why the decision was made to just
zero out that bit too.

<SNIP!>

> 3.2.3.1.2  ICV Computation for IPv6
<SNIP!>

>    *** Do we want to make any recommendation for what an AH implementation
>    *** should do if it encounters an unfamiliar IPv6 extension header,
>    *** e.g., Routing Header "Type 1" (aka Nimrod)?

IMHO, new IPv6 extensions should document their own AH properties.  Keep in
mind this is IMHO only.

> 3.2.3.2  Padding
> 
> 3.2.3.2.1  Authentication Data Padding
> 
>    As mentioned in section 2.6, the Authentication Data field explicitly
>    includes padding to ensure that the AH header is a multiple of 32
>    bits (IPv4) or 64 bits (IPv6).  If padding is required, its length is
>    determined by three factors:
>              - the presence or absence of the Sequence Number field
>              - the length of the ICV
>              - the IP protocol context (v4 or v6)
> 
>    For example, if the Sequence Number field is present and a default,
>    96-bit truncated HMAC algorithm is selected, no padding is required
>    for either IPv4 nor IPv6.  In contrast, if the anti-replay service is
>    not selected, and a default 96-bit truncated HMAC algorithm is
>    selected, no padding is required for IPv4, but 4 bytes of padding are
>    required for IPv6.  The content of the padding field is arbitrarily
>    selected by the sender.  (The padding is arbitrary, but need not be
>    random to achieve security.)  These bytes are included in the
>    Authentication Data calculation, counted as part of the Payload
>    Length, and transmitted at the end of the Authentication Data field
>    to enable the receiver to perform the ICV calculation.

Thank you!  We in IPv6-land appreciate this.

<SNIP!>

> 3.2.3.3  Authentication Algorithms
> 
>    The authentication algorithm employed for the ICV computation is
>    specified by the SA.  For point-to-point communication, suitable
>    authentication algorithms include keyed Message Authentication Codes
>    (MACs) based on symmetric encryption algorithms (e.g., DES) or on
>    one-way hash functions (e.g., MD5 or SHA-1).  For multicast
>    communication, one-way hash algorithms combined with asymmetric
>    signature algorithms are suitable.

As an aside, has anyone tackled this?  A lightweight digital signature
algorithm would be perfect in a multicast environment with a small number of
senders compared with an arbitrary number of receivers.

LARGE number of senders, however, requires Real Work (TM).

>    As of this writing, the mandatory-to-implement authentication algorithms
>    are based on the former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or
>    HMAC with MD5 [Riv92].  The output of the HMAC computation is truncated
>    to (the leftmost) 96 bits.  Other algorithms, possibly with different
>    ICV lengths, MAY be supported.

Like I mentioned before, as currently written, these I-Ds _always_ include
the replay counter.  The replay counter is set to 0 for associations that
don't use replay.

<SNIP!>

> 3.3  Inbound Packet Processing
<SNIP!>

> 3.3.3  Sequence Number Verification
> 
>    If the anti-replay service has been selected for this SA, the
>    receiver MUST verify that the packet contains a Sequence Number that
>    does not duplicate the Sequence Number of any other packets received
>    during the life of this SA.  This SHOULD be the first AH check
>    applied to a packet after it has been matched to an SA, to speed
>    rejection of duplicate packets.

Ummm, what if I live in a multithreaded world?  I can theoretically get two
packets near-concurrently with the same sequence number.  If the bogus one
arrives first, do I trash the good one just because one with the same replay
number arrived first?  Or do I not count a sequence number as "good" until
I've authenticated?  Or is this just an implementation detail?  Or is this
why it says SHOULD rather than MUST?

<SNIP!>

>    DISCUSSION:
> 
>       Note that if the packet is either inside the window and new, or
>       outside the window on the "right" side, the receiver MUST
>       authenticate the Sequence Number field before updating the bit
>       mask (either turning on a bit or updating the "right" side of the
>       window).

Ahhhh, I get it now.  I left the questions in because this is how some might
think as they read it.

<SNIP!>

I guess that's it for pass one.  As I see more things, I'll report them.

Dan


Follow-Ups: References: