Subject: [Isms] review of draft-ietf-isms-transport-security-model-02

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Feb 2007 14:58:46 +0100

Hi,

I have gone through this document and I have a few comments; most of
them I think are rather easy to resolve.

a) spell out AAA the first time this acronym is used

b) p6:

   s/authenticatio and/authentication and/

c) The document in several places talks about transportType but this
   really is transportDomain called in the architecture and the ASIs.

d) p7:

   s/modles/models/

   In the paragraph, change "security" to "security model".

e) There are places with quite some repetitions - cutting the
   repetions might shorten the ID quite a bit. For example, section 3
   repeats many details from RFC 3412 - this could be much shorter by
   just stating which things actually change. It is also stated
   multiple times how the securityLevel and the level of s ecurity
   provided by the transport relate.

f) I am confused about msgSecurityParameters. Does it simply encode to
   '0400'h or does it contain a ber serialization of a zero length
   octet string, that is '04020400'? I was hoping the first option,
   but the ASN.1 definition (which should be (SIZE (0))) makes me
   believe the second option is meant.

g) The first step in the EoP (section 4.2) seems interesting since you
   try to verify that the message processing model did its work
   correctly. We do not have such a check in the USM as far as I can
   tell and I am not sure we should go down that path of verifying
   everywhere that the other parts of the system work correctly.

h) Step 4 in the EoP again seems to step on what RFC 3412 is doing
   (see step 7e) in section 7.1 or RFC 3412).

i) Step 5 in the EoP also seem to be covered by RFC 3412 7e).

j) In step 9, I suggest to drop "and securityParameters (a zero-length
   octet string)" since you can't return a wholeMsg without it.

k) Like before, I question the need for step 1) in section 5.2.

l) You want to capitalize the beginning of all steps in section 5.

m) Section 6.2. can probably be removed because the MIB does not use
   any TCs.

n) In section 8, I am not sure the phrase ", for access control
   purposes" is particularly clear. I would suggest to drop it. If you
   keep it, you probably have to spend some more text to explain what
   goes into an access control decision (but since we do not change
   anything, I think such an explanation is not needed).

o) p21:

   s/Secuirty/Security/

p) Are RFCs 3413, 3414, 3416, 3584 really all normative references?

Dave, perhaps you can take a look at my list above and post a new
ID. Since I believe the text is fairly complete, we can consider to
move this document into last call mode so that we get more people to
look at this in more detail before the meeting in Prague.

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Thu, 22 Feb 2007 21:16:32 -0500

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Tuesday, February 13, 2007 8:59 AM
> To: David Harrington
> Cc: [email-masked]
> Subject: review of draft-ietf-isms-transport-security-model-02
> 
> Hi,
> 
Done.
>    s/authenticatio and/authentication and/
Done.
>    really is transportDomain called in the architecture and the
ASIs.
Done.
>    s/modles/models/
done
>    In the paragraph, change "security" to "security model".
Done.

>    provided by the transport relate.
Done.

>    believe the second option is meant.
Changed to an OCTET STRING SIZE(0) - '0400'

>    everywhere that the other parts of the system work correctly.
Removed.

>    (see step 7e) in section 7.1 or RFC 3412).
Removed.
> i) Step 5 in the EoP also seem to be covered by RFC 3412 7e).
Removed.
>    octet string)" since you can't return a wholeMsg without it.

securityParameters is an OUT parameter. I don't know why, since
rfc3412 doesn't describe any subsequent processing for that parameter,
but it is in the ASIs between ther MPM and the SM.

> k) Like before, I question the need for step 1) in section 5.2.
Done.
> l) You want to capitalize the beginning of all steps in section 5.
Done (also for section 4).
> m) Section 6.2. can probably be removed because the MIB does not use
Done.
>    anything, I think such an explanation is not needed).
Removed.
>    s/Secuirty/Security/
Done.
> p) Are RFCs 3413, 3414, 3416, 3584 really all normative references?

3413 defines application types that are referenced; a reader will need
to undersand those types. That makes it normative.

3414 changed 3414 and 3584 to informative

Eliminated all reference to rfc3416.