IS-IS Generic Cryptographic Authentication
RFC 5310

Received changes through RFC Editor sync (changed abstract to 'This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.

Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]')

[Ballot comment]
Figure 1:

                  0                  1
                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |    Type 10  |    Length    |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |  Auth Type  |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |            Key ID            |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |                              |
                  +                              +
                  | Authentication Data (Variable)|
                  +                              +
                  |                              |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I found the formatting confusing. Does the missing
fourth octet mean that it is (a) reserved or (b)
omitted and Auth Type and Key ID are actually consequtive
fields? Please clarify.

[Ballot comment]
Section 4., paragraph 7:
>    [RFC4086] contains helpful information on both key
>    generation techniques and cryptographic randomness.

  [RFC4086] isn't mentioned in the references.

IANA Last Call comments:

Upon approval of this document, the IANA will add the following
to the "IS-IS Authentication Type Codes for TLV 10" registry at
http://www.iana.org/assignments/isis-tlv-codepoints

Reference: [RFC-isis-hmac-sha-05]
Registration Procedures: Expert Review
Initial contents of this sub-registry will be:

Value Authentication Type Code Reference
----- --------------------------- ---------
3 Cryptographic Authentication [RFC-isis-hmac-sha-05]

We understand the above to be the only IANA Action for this document.

PROTO Questionnaire and Write-up for: draft-ietf-isis-hmac-sha-04.txt

Shepherding WG-Chair: Chris Hopps (chopps@rawdofmt.org)

Questionnaire

    Q1) Have the chairs personally reviewed this version of the
    Internet Draft (ID), and in particular, do they believe
    this ID is ready to forward to the IESG for publication?

A1) Yes.

    Q2) Has the document had adequate review from both key WG
    members and key non-WG members? Do you have any concerns
    about the depth or breadth of the reviews that have been
    performed?

A2) Adequately reviewed.

    Q3) Do you have concerns that the document needs more review
    from a particular (broader) perspective (e.g., security,
    operational complexity, someone familiar with AAA, etc.)?

A3) No concerns.

    Q4) Do you have any specific concerns/issues with this
    document that you believe the ADs and/or IESG should be
    aware of? For example, perhaps you are uncomfortable with
    certain parts of the document, or have concerns whether
    there really is a need for it. In any event, if your issues
    have been discussed in the WG and the WG has indicated it
    that it still wishes to advance the document, detail those
    concerns in the write-up.

A4) No concerns.

    5) How solid is the WG consensus behind this document? Does
    it represent the strong concurrence of a few individuals,
    with others being silent, or does the WG as a whole understand
    and agree with it?

A5) Strong Consensus.

    6) Has anyone threatened an appeal or otherwise indicated
    extreme discontent? If so, please summarise the areas of
    conflict in separate email to the Responsible Area Director.

A6) No.

    7) Have the chairs verified that the document adheres to
    all of the ID Checklist items ?

A7) Yes.

    8) Is the document split into normative and informative
    references?  Are there normative references to IDs, where
    the IDs are not also ready for advancement or are otherwise
    in an unclear state? (note here that the RFC editor will
    not publish an RFC with normative references to IDs, it
    will delay publication until all such IDs are also ready
    for publication as RFCs.)

A8) The normative reference to RFC3567 is to an informational
    RFC. The standards track replacement is currently awaiting
    RFC number assignedment and it should replace this reference.

    9) What is the intended status of the document? (e.g.,
    Proposed Standard, Informational?)

A9) Proposed Standard.

*** Write-up


** Technical Summary

This document updates the cryptographic security mechanism currently
deployed for IS-IS. Two key improvements are realized with the new
document. The first is the specification of stronger hash algorithms
(SHA-X) to replace the less strong MD5 algorithm used in the previous
specification. The second improvement is to establish the use of
key IDs to allow for better specification of security associations.
This allows for more efficient key replacement in an operating network.

** Working Group Summary

The consensus was moderately strong for this specification. The
specification updates an older security mechanism that various
consumers have deemed insecure (MD5) and thus cannot be used. The
need for the new scheme was accepted in the end with no controversy.
During development 2 conflicting but very similiar drafts
were merged with both sets of authors now present on the current
document.

** Protocol Quality

There are currently no implementations of this specification.  As
noted in the "Working Group Summary" there is a need in the community
to replace the current cryptographic method used in IS-IS, with one
that allows for more secure hashing algorithms. At least one author
off the document is considered to be a security expert so the
security review is considered strong.