Subject: Gen-ART LC review of draft-ietf-isis-hmac-sha-05

From: Ben Campbell <[email-masked]>
Date: Tue, 28 Oct 2008 16:37:46 -0500

Document: draft-ietf-isis-hmac-sha-05
Reviewer: Ben Campbell	
Review Date:  2008-10-28
IETF LC End Date: 2008-11-04
IESG Telechat date: (if known)

Summary:

This draft is almost ready for publication as an RFC. (The draft does  
not identify the intended status--I assume it to be standards track).  
I have some questions that should be addressed first, as well as some  
minor editorial comments.

Comments:

Substantive:

-- The draft does not state its intended status.

-- The draft suggests that this extension can be used for arbitrary  
cryptographic authentication mechanisms, and defines how it is used  
for HMAC-SHA. However, I found no text on how to extend it for other  
mechanisms. For example, is the hash algorithm list intended to be  
extensible? Should there be an IANA table for that, then? Are the  
parameters in this new authentication type assumed to be sufficient  
for any arbitrary mechanism?

-- Section 2, first bullet point:

Can you provide motivation for a single octet length for Key ID? I'm  
not saying this is wrong; just that it would be good to know that this  
is a considered choice rather than an arbitrary one. My instinct is to  
wonder if limiting the Key-ID space to 256 values is too small. Also,  
it would be good to mention that administrators will need to keep the  
Key-ID assignments consistent between members of an SA.

-- Section 2, second bullet:

How is the selected algorithm encoded into the 1-octet Authentication  
Algorithm field?

-- Section 3.5, 2nd to last paragraph:

I suspect this paragraph has significant security considerations that  
should be addressed in section 4.

-- Section 3.5, last paragraph:

This paragraph seems to make a normative statement about  
implementations that _don't_ implement this extension. Is that the  
intent?

Editorial:

-- Section 1, first paragraph: Lots of acronyms here--please consider  
expanding on first use.

-- Section 1, last paragraph: I suggest scoping this statement with  
something to the effect of "At the time of this writing, no openly  
published..."

-- Section 3.2: 

I assume the area, link, and domain authenticated strings are  
described in the original IS-IS doc? If so, can you reference them by  
section?

-- Section 3.3, "K" -- Can you provide a reference for ISO 10589?

-- Section 8

The author list here does not match the first page. Should some of  
these move to a "Contributors" section?

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Ben Campbell <[email-masked]>
Date: Tue, 28 Oct 2008 16:44:54 -0500

I got a failure report for  [email-masked] . Can that be updated to a  
current address prior to publication?

Thanks!

Ben.

On Oct 28, 2008, at 4:37 PM, Ben Campbell wrote:

> This draft is almost ready for publication as an RFC. (The draft  
> does not identify the intended status--I assume it to be standards  
> track). I have some questions that should be addressed first, as  
> well as some minor editorial comments.
>
> Comments:
>
> Substantive:
>
> not saying this is wrong; just that it would be good to know that  
> this is a considered choice rather than an arbitrary one. My  
> instinct is to wonder if limiting the Key-ID space to 256 values is  
> too small. Also, it would be good to mention that administrators  
> will need to keep the Key-ID assignments consistent between members  
> of an SA.
>
> How is the selected algorithm encoded into the 1-octet  
> Authentication Algorithm field?
>
> I suspect this paragraph has significant security considerations  
> that should be addressed in section 4.
>
> -- Section 1, first paragraph: Lots of acronyms here--please  
> consider expanding on first use.
>
> described in the original IS-IS doc? If so, can you reference them  
> by section?
>

---

From: Scott Brim <[email-masked]>
Date: Tue, 28 Oct 2008 14:54:21 -0700

> current address prior to publication?

Just fyi he's [email-masked]

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Wed, 29 Oct 2008 07:05:44 +0530

Hi Ben,

Thanks for the quick review. Please find my comments inline.

> -- The draft does not state its intended status.

Will fix this. It's a standards track.

> mechanisms. 

We have some text with effect to this in Sec 2. It is a well known
mechanism to use the Key IDs to identify the keys used at the two ends.
The receiving router needs to do a local lookup against the key ID to
determine which authentication algorithm, the secret key, needs to be
used for the incoming packet. The assumption was that any reader
proficient enough to understand (or implement) this document would be
aware of how the Key IDs are used.

> For example, is the hash algorithm list intended to be  

There is no need for this as the Key ID gives all this information.

> for any arbitrary mechanism?

Yes. Assume that a new authentication algorithm is invented in future
which takes some "n" additional parameters for its operation. We don't
need to specify these parameters in our PDU. All we need to do is to
have a Key ID which maps to an SA, which in turn stores those additional
parameters. All one needs to ensure is that the two ends have the same
view of that Key ID. Using a Key ID is not new in IETF and the details
of how these are established is beyond the scope of this document.

> wonder if limiting the Key-ID space to 256 values is too 

I agree. I think we should extend this to 4 octets.

> Key-ID assignments consistent between members of an SA.

Sure, this can be done.

> How is the selected algorithm encoded into the 1-octet 

Section 2 details the parameters associated by the ISIS Security
association indexed by the Key ID. One does not need to carry this in
the ISIS PDU. Its, as I mentioned above, derived at the receiving end by
a lookup done against the Key ID.
 
> should be addressed in section 4.

Sure, will do that.

> implementations that _don't_ implement this extension. Is that the  

Yes, it was intentional.
 
> -- Section 1, first paragraph: Lots of acronyms here--please 

Ok, will do that.

> something to the effect of "At the time of this writing, no openly  

Ok.

> described in the original IS-IS doc? If so, can you reference 

Sure.

> -- Section 3.3, "K" -- Can you provide a reference for ISO 10589?

Ok.

> these move to a "Contributors" section?

Will fix this. 

Cheers,
Manav

---

From: Ben Campbell <[email-masked]>
Date: Tue, 28 Oct 2008 20:38:58 -0500

I made an editorial comment in my gen-art review of draft-ietf-isis- 
hmac-sha-05, below:

> these move to a "Contributors" section?

I have since had off-line discussions to indicate:

1) The RFC editor policy allows this difference in general, and

2) Even if they didn't, this draft is the product of merging two  
original drafts, which resulted in the current author list. That is,  
the author list seems reasonable in this specific case.

Therefore, I withdraw that comment.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Ben Campbell <[email-masked]>
Date: Tue, 28 Oct 2008 20:43:05 -0500

Thanks!

I will address your other responses separately, but I wanted to hit  
this one quickly:

>> these move to a "Contributors" section?

Please see my other comment on this subject in a separate email before  
making any changes. To recap, I am convinced that I was mistaken in  
that particular comment, so don't change it on my account.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Oct 2008 14:25:54 -0500

Thanks--comments imbedded. I have edited out items that I think are  
closed.

In summary, you have addressed all of my substantive comments.  
Anything remaining is editorial, and minor at that.

[...]

>> for HMAC-SHA. However, I found no text on how to extend it for other

On re-reading the section, I realize that I mistakenly thought the  
Auth-Type field in the new TLV carried the selected hash algorithm. I  
now realize that this field is only there for backwards compatibility,  
and merely indicates you are using this specific authentication model,  
as opposed to one of the legacy mechanisms. So nevermind :-)

[...]

> a lookup done against the Key ID.

This comment was related to the misread I mentioned above--so, again,  
nevermind :-)

[...]

>> implementations that _don't_ implement this extension. Is that the

Let me push on that a minute--how can this draft make normative  
statements about implementations that don't support this draft? To put  
a sharper point on it, you can't assume that someone who is not  
implementing this draft will even read this draft.

If you are in fact describing existing behavior rather than specifying  
a new normative requirement, then it would probably be better to avoid  
normative language, or state is in the form of "according to RFC XXXX,  
implementations MAY..."

(On the other hand, since this is a MAY, it's probably less of an  
issue than if it were a stronger normative statement.)

>> these move to a "Contributors" section?

See other emails on this one.

Thanks!

Ben.

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Thu, 30 Oct 2008 05:07:54 +0530

> issue than if it were a stronger normative statement.)

Upon rereading this particular text I realize that its redundant and can
be safely pruned. This is because implementations that don't support
this draft are anyways going to accept the PDUs as per the standards. I
was only trying to restate the obvious.

Will remove this in the revised ID.

> See other emails on this one.

I will move all the authors in the list at the top of the document as
suggested by Chris in the revised ID.

Cheers,
Manav

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Oct 2008 20:30:19 -0500

> Will remove this in the revised ID.

I don't object to removing it--but if you think that saying it  
provides any help for implementers of this extension, you could also  
fix this by merely stating it in non-normative language.

In either case, the discussion has addressed all of my comments.

Thanks!

Ben.