Internet Security Glossary, Version 2
RFC 4949

Note: This ballot was opened for revision 08 and is now closed.

(Russ Housley) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2006-09-28 for -)
No email
send info
> (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 No Objection

(Magnus Westerlund) No Objection

Comment (2006-09-28 for -)
No email
send info
I am somewhat worried about the less than correct description of some words, like TCP. Lets discuss this.

(Lisa Dusseault) Abstain

(Bill Fenner) (was No Objection) Abstain

Comment (2006-09-27 for -)
No email
send info
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.

(Sam Hartman) Abstain

Comment (2006-09-27 for -)
No email
send info
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

That said, I continue to appreciate the tremendous work that has gone
into this document and RFC 2828.

(Dan Romascanu) (was Discuss) Abstain

Comment (2006-09-28)
No email
send info
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