Internet Security Glossary, Version 2
draft-shirey-secgloss-v2-08
Yes
(Russ Housley)
No Objection
(Lars Eggert)
Abstain
(Lisa Dusseault)
Note: This ballot was opened for revision 08 and is now closed.
Russ Housley Former IESG member
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2006-09-28)
Unknown
> (I) A extension framework for PPP that supports multiple, optional
> authentication mechanisms, including cleartext passwords,
> challenge-response, and arbitrary dialog sequences. [R3748]
Please rewrite as "An authentication framework that supports different
authentication methods, including cleartext passwords,
challenge-response, certificates, shared secrets, SIM cards, and so
on.", or something to that effect. As you note below it is not merely
for PPP. And the EAP term is "methods", not "mechanisms". Finally,
the set of methods would be good to update.
> $ IKE
> (I) See: IPsec Key Exchange.
I think you mean Internet Key Exchange.
> $ Remote Authentication Dial-In User Service (RADIUS)
Consider adding a definition for Diameter as well, and a generic
term for AAA.
> $ Internet Key Exchange (IKE)
> (I) An Internet, IPsec, key-establishment protocol [R4306] for
> putting in place authenticated keying material (a) for use with
> ISAKMP and (b) for other security associations, such as in AH and
> ESP.
>
> Tutorial: IKE is based on three earlier protocol designs: ISAKMP,
> OAKLEY, and SKEME.
Question: is all of this still valid with IKEv2?
> Tutorial: If IP were used in an OSIRM stack, IP would be placed at
> the top of Layer 3, above other Layer 3 protocols in the stack.
>
> In any IPS stack, IP is always present in the Internet Layer and
> is always placed at the top of that layer, on top of any other
> protocols that are used in that layer. In some sense, IP is the
> only protocol specified for the IPS Internet Layer; other
> protocols used there, such as AH and ESP, are just IP variations.
My head hurts when I try to understand this definition.
What would the other protocols in Internet Layer be?
If there are such protocols, e.g., AH/ESP/HIP/SHIM/MIP/etc,
they are not necessarily under IP.
> 2. Envy: Poor Data Link is always starved for attention. (With
> Asynchronous Transfer Mode, maybe now it is feeling less
> neglected.)
Perhaps this should be written as
2. Envy: Poor Data Link is always starved for attention. (Back
in the times of the Asynchronous Transfer Mode, it was
feeling a lot less neglected.)
Lars Eggert Former IESG member
No Objection
No Objection
(2006-09-27)
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
(2006-09-28)
Unknown
I am somewhat worried about the less than correct description of some words, like TCP. Lets discuss this.
Bill Fenner Former IESG member
(was No Objection)
Abstain
Abstain
(2006-09-27)
Unknown
While newtrk's ISD proposal never went anywhere, it was (in my experience) the introduction of the term ISD to the IETF. This document uses ISD to refer to (as far as I can tell) RFCs; I think doing so will create confusion.
Dan Romascanu Former IESG member
(was Discuss)
Abstain
Abstain
(2006-09-28)
Unknown
1. 'community string' article - This article is mis-representing what community strings were meant to be in SNMPv1 and SNMPv2. None of RFC 1157 or RFC 1901 referenced here defines community string as a 'cleartext password'. I would suggest that these references be consulted for a proper definition of the term. 2. 'Simple Network Management Protocol' article - SNMP is not 'TCP-based'. Also it is no longer solely defined to pass information between managers and agents 3. The 'Standards for Interoperable LAN/MAN Security (SILS)' article mentions IEEE 802.10 which was deprecated by the IEEE, but ignores the more recent work on security in IEEE 802.1 like IEEE 802.1X and IEEE 802.1AE 4. 'IEEE 802.10' article - The IEEE 802.10 Working Group was shut down a few years ago, while a Security Task Force was formed since 2002 in IEEE 802.1 as has now taken over principal responsibilities related to security standards in the IEEE 802. I suggest taking out this article or mentioning that 802.10 is historical and include an article about the IEEE 802.1 security task force 5. 'WEP' article - I find strange for a document published in 2006 or 2007 to dedicate an article to WEP without any discussion about its vulnerabilities, and ignore IEEE 802.11i
Lisa Dusseault Former IESG member
Abstain
Abstain
()
Unknown
Sam Hartman Former IESG member
Abstain
Abstain
(2006-09-27)
Unknown
I appreciate that a lot of work has gone into this draft and into the security glossary. However there is a lot left in the glossary that is the author's personal opinion. We found a number of instances where the author was trying to use this glossary to establish normative meanings for words based on his belief of how those words should be used--sometimes in direct conflict with common practice. I think RFC 2828 is very useful, but I question whether the added length of this document and the cases in which definitions reflect the author's bias rather than the actual use of terms will enhance or reduce the utility of this document over RFC 2828. My recommendation is that if the rfc editor chooses to publish this document, that it not obselete RFC 2828 and that the RFC editor make it quite clear that this is the author's personal opinions about these terms. That said, I continue to appreciate the tremendous work that has gone into this document and RFC 2828.