Internet Security Glossary, Version 2
draft-shirey-secgloss-v2-08
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the Abstain position for Dan Romascanu |
|
2007-08-29
|
08 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2007-08-29
|
08 | Amy Vezza | [Note]: 'RFC 4949<br>FYI 0036' added by Amy Vezza |
|
2007-08-20
|
08 | (System) | RFC published |
|
2006-11-15
|
08 | (System) | New version available: draft-shirey-secgloss-v2-08.txt |
|
2006-11-13
|
08 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2006-10-02
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2006-10-02
|
08 | Amy Vezza | IESG has approved the document |
|
2006-10-02
|
08 | Amy Vezza | Closed "Approve" ballot |
|
2006-09-29
|
08 | (System) | Removed from agenda for telechat - 2006-09-28 |
|
2006-09-28
|
08 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza |
|
2006-09-28
|
08 | Dan Romascanu | [Ballot comment] 1. 'community string' article - This article is mis-representing what community strings were meant to be in SNMPv1 and SNMPv2. None of RFC … [Ballot comment] 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 |
|
2006-09-28
|
08 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to Abstain from Discuss by Dan Romascanu |
|
2006-09-28
|
08 | Jari Arkko | [Ballot comment] > (I) A extension framework for PPP that supports multiple, optional > authentication mechanisms, including cleartext passwords, > challenge-response, and arbitrary dialog sequences. … [Ballot comment] > (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.) |
|
2006-09-28
|
08 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
|
2006-09-28
|
08 | Jari Arkko | [Ballot discuss] |
|
2006-09-28
|
08 | Bill Fenner | [Ballot Position Update] Position for Bill Fenner has been changed to Abstain from No Objection by Bill Fenner |
|
2006-09-28
|
08 | Jari Arkko | [Ballot discuss] > (I) A extension framework for PPP that supports multiple, optional > authentication mechanisms, including cleartext passwords, > challenge-response, and arbitrary dialog sequences. … [Ballot discuss] > (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. COMMENT-only part: > $ 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.) |
|
2006-09-28
|
08 | Lisa Dusseault | [Ballot Position Update] New position, Abstain, has been recorded by Lisa Dusseault |
|
2006-09-28
|
08 | Jari Arkko | [Ballot discuss] > (I) A extension framework for PPP that supports multiple, optional > authentication mechanisms, including cleartext passwords, > challenge-response, and arbitrary dialog sequences. … [Ballot discuss] > (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. COMMENT-only part: > $ 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. |
|
2006-09-28
|
08 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
|
2006-09-28
|
08 | Magnus Westerlund | [Ballot comment] I am somewhat worried about the less than correct description of some words, like TCP. Lets discuss this. |
|
2006-09-28
|
08 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2006-09-27
|
08 | Sam Hartman | [Ballot comment] I appreciate that a lot of work has gone into this draft and into the security glossary. However there is a lot left … [Ballot comment] 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. |
|
2006-09-27
|
08 | Sam Hartman | [Ballot Position Update] New position, Abstain, has been recorded by Sam Hartman |
|
2006-09-27
|
08 | Bill Fenner | [Ballot comment] While newtrk's ISD proposal never went anywhere, it was (in my experience) the introduction of the term ISD to the IETF. This document … [Ballot comment] 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. |
|
2006-09-27
|
08 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner |
|
2006-09-27
|
08 | Yoshiko Fong | IANA Evaluation Comment: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2006-09-27
|
08 | Dan Romascanu | [Ballot discuss] 1. 'community string' article - This article is mis-representing what community strings were meant to be in SNMPv1 and SNMPv2. None of RFC … [Ballot discuss] 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 |
|
2006-09-27
|
08 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
|
2006-09-27
|
08 | Lars Eggert | [Ballot comment] |
|
2006-09-26
|
08 | Lars Eggert | [Ballot comment] Has a huge list of missing references, uncited references and violates many idnits. Should really be fixed before this hits the RFC Editor. |
|
2006-09-26
|
08 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2006-09-25
|
08 | Russ Housley | Placed on agenda for telechat - 2006-09-28 by Russ Housley |
|
2006-09-25
|
08 | Russ Housley | State Changes to IESG Evaluation from AD Evaluation by Russ Housley |
|
2006-09-25
|
08 | Russ Housley | [Ballot Position Update] New position, Yes, has been recorded for Russ Housley |
|
2006-09-25
|
08 | Russ Housley | Ballot has been issued by Russ Housley |
|
2006-09-25
|
08 | Russ Housley | Created "Approve" ballot |
|
2006-09-25
|
08 | (System) | Ballot writeup text was added |
|
2006-09-25
|
08 | (System) | Last call text was added |
|
2006-09-25
|
08 | (System) | Ballot approval text was added |
|
2006-09-25
|
08 | Russ Housley | State Changes to AD Evaluation from Publication Requested by Russ Housley |
|
2006-09-14
|
08 | Amy Vezza | Shepherding AD has been changed to Russ Housley from Brian Carpenter |
|
2006-09-14
|
08 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
|
2006-09-10
|
07 | (System) | New version available: draft-shirey-secgloss-v2-07.txt |
|
2006-08-30
|
06 | (System) | New version available: draft-shirey-secgloss-v2-06.txt |
|
2006-08-25
|
05 | (System) | New version available: draft-shirey-secgloss-v2-05.txt |
|
2006-03-23
|
04 | (System) | New version available: draft-shirey-secgloss-v2-04.txt |
|
2006-02-21
|
03 | (System) | New version available: draft-shirey-secgloss-v2-03.txt |
|
2005-11-11
|
02 | (System) | New version available: draft-shirey-secgloss-v2-02.txt |
|
2005-03-09
|
01 | (System) | New version available: draft-shirey-secgloss-v2-01.txt |
|
2004-08-23
|
00 | (System) | New version available: draft-shirey-secgloss-v2-00.txt |