Skip to main content

Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)
draft-arkko-pppext-eap-aka-16

Revision differences

Document history

Date Rev. By Action
2012-08-22
16 (System) post-migration administrative database adjustment to the Yes position for Thomas Narten
2012-08-22
16 (System) post-migration administrative database adjustment to the No Objection position for Sam Hartman
2012-08-22
16 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2005-10-25
(System) Posted related IPR disclosure: Nokia Corporation's statement about IPR claimed in draft-arkko-pppext-eap-aka-15.txt
2005-02-10
16 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-02-09
16 Amy Vezza IESG state changed to Approved-announcement sent
2005-02-09
16 Amy Vezza IESG has approved the document
2005-02-09
16 Amy Vezza Closed "Approve" ballot
2005-02-09
16 Thomas Narten State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Thomas Narten
2005-02-09
16 Thomas Narten [Note]: '2005-02-09: IANA questions resolved; document can (finally!) be
approved.
' added by Thomas Narten
2005-02-09
16 Thomas Narten [Ballot Position Update] Position for Thomas Narten has been changed to Yes from Discuss by Thomas Narten
2005-02-04
16 Michelle Cotton
Follow-up comments from Jari Arkko to IANA:
>>For  here are some questions:
>
>
>>In the current eap-numbers registry, there is an entry for 23 …
Follow-up comments from Jari Arkko to IANA:
>>For  here are some questions:
>
>
>>In the current eap-numbers registry, there is an entry for 23 called
>>UMTS Authentication and Key Agreement.  Is this the same type number?
>>Should the name and reference be changed?

Yes.

uld the parameters described in this document be in a NEW Separate
>>Registry?  For example "EAP-AKA and EAP-SIM Parameters"?  Within this
>>registry would be the subtypes, attribute types, and all codes, under
>>the attribute types.

This is largely up to you, we can live whether the parameters are in a separate place or together in the EAP registry (http://www.iana.org/assignments/eap-numbers). But my preference is a separate registry. Your name suggestion sounds good, and maybe file name "eapsimaka-numbers" or something along those lines.

>>For those numbers not assigned in this document, should they be marked
>>as "Unassigned"?

Yes.

>>Will there be an expert to determine if a non-RFC document is sufficient?

I believe the document says "Specification Required" only, and gives some explicit examples about non-RFC documents that might request attribute etc. allocations.

>>I will enter these comments in the tracker so that they do not get lost.
>
>
>>For , my comments in the
>>tracker indicate that I only need to change the reference for a
>>parameter in the eap-numbers registry.  Maybe we held this one because
>>of its relationship to the arkko-pppext document.

Right.

Hope this cleared all the questions. Thanks for looking at the IANA parts of our documents.

--Jari
2005-02-01
16 Michelle Cotton
IANA Comments:
In the current eap-numbers registry, there is an entry for 23 called UMTS Authentication and Key Agreement.  Is this the same type number? …
IANA Comments:
In the current eap-numbers registry, there is an entry for 23 called UMTS Authentication and Key Agreement.  Is this the same type number?
Should the name and reference be changed?

Should the parameters described in this document be in a NEW Separate Registry?  For example "EAP-AKA and EAP-SIM Parameters"?  Within this registry would be the subtypes, attribute types, and all codes, under the attribute types.

For those numbers not assigned in this document, should they be marked as "Unassigned"?

Will there be an expert to determine if a non-RFC document is sufficient?
2005-01-03
16 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2004-12-29
16 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman
2004-12-28
16 Russ Housley
[Ballot discuss]
My original concern was:

  I have concerns about the security of these in many environments.  It
  seems like these were designed …
[Ballot discuss]
My original concern was:

  I have concerns about the security of these in many environments.  It
  seems like these were designed for a particular threat environment, but
  making them available as EAP methods makes it very easy for them to be
  used in inappropriate environments.

  The note from Thomas indicates that the IETF has not done a complete
  review, and it will not do a security review.  I believe that we should
  add an IESG note that documents the situation.

A proposed IESG note was added to the document.  However, I think the
note should also say that it is infeasible to evaluate the security of
the protocols without specification of all cryptographic algorithms used.
Part of the specifiecation requires AES, but other cryptographic algorithms
are included by reference to documents that are not readily available.
2004-12-27
16 (System) New version available: draft-arkko-pppext-eap-aka-16.txt
2004-12-27
15 (System) New version available: draft-arkko-pppext-eap-aka-15.txt
2004-12-03
16 (System) Removed from agenda for telechat - 2004-12-02
2004-12-02
16 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2004-12-02
16 Thomas Narten [Ballot discuss]
IANA has some questions.
2004-12-02
16 Thomas Narten [Ballot Position Update] Position for Thomas Narten has been changed to Discuss from Yes by Thomas Narten
2004-12-02
16 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2004-12-02
16 Russ Housley
[Ballot discuss]
I have concerns about the security of these in many environments.  It
  seems like these were designed for a particular threat environment, …
[Ballot discuss]
I have concerns about the security of these in many environments.  It
  seems like these were designed for a particular threat environment, but
  making them available as EAP methods makes it very easy for them to be
  used in inappropriate environments.

  The note from Thomas indicates that the IETF has not done a complete
  review, and it will not do a security review.  I believe that we should
  add an IESG note that documents the situation.
2004-12-02
16 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley
2004-12-02
16 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-12-01
16 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-12-01
16 Sam Hartman
[Ballot discuss]
There seem to be two types of mutual authentication in the EAP
community.  Some EAP methods authenticate the identity of the
authenticator while …
[Ballot discuss]
There seem to be two types of mutual authentication in the EAP
community.  Some EAP methods authenticate the identity of the
authenticator while other methods that provide mutual authentication
only authenticate the identity of the EAP server.  RFC 3748 seems a
bit unclear on this distinction although the issue appears to be
under active discussion in the working group.


As best I can tell, this method only authenticates the identity of
the EAP server.  If true, section 11.2 should be revised.  Here is
proposed text  for a new section 11.2:

  EAP-AKA provides mutual authentication of the peer and the EAP
server via the 3rd generation AKA
  mechanisms [TS 33.102] and [S.S0055-A].
  However, the identity of the authenticator is not authenticated to
the peer.  As a result, an attacker may be able to trick a peer in
to choosing an authenticator different than the one the peer planned
to use if both authenticators use the same EAP server.  If the
authenticators have different attributes such as price or available
services then the attacker may force the peer to choose the
authenticator with attributes preferred by the attacker.
2004-12-01
16 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to Discuss from Yes by Sam Hartman
2004-12-01
16 Sam Hartman [Ballot Position Update] New position, Yes, has been recorded for Sam Hartman by Sam Hartman
2004-12-01
16 Harald Alvestrand
Review from Joel Halpern, Gen-ART

This document is ready for publication as an Information RFC.

I have one minor concern:
  The whole AKA-Notification mechanism, …
Review from Joel Halpern, Gen-ART

This document is ready for publication as an Information RFC.

I have one minor concern:
  The whole AKA-Notification mechanism, if I have understood it, seems to be based on a concern that something is wrong with EAPs underlying notification / success / failure mechanism.  Just blithely re-implementing an existing mechanism (apparently for reasons of localization support) seems something that should be treated a little more seriously than appears here.  Have the EAP folks looked at this question?

nits, if there is some other reason to rev the document:
  The use of "authenticator" and "peer" is probably standard EAP terminology, but was confusing to me.  I assume that "authenticator" corresponds to the entity which knows who is a valid subscriber, and who is not.  Some of the text indicates that EAP runs to the handset, so I assume that the handset is the "peer"?  Just including "peer" in the list of terms would probably solve this.

  In section 4.1.1.1 there is a description of an IMSI.  It describes various fields and their sizes.  It then says "In other words, the IMSI is a string of not more than 15 digits."  While this is a true statement, it is an addition to the previous wording (which would otherwise lead the reader to determine that an IMSI could be 16 digits.)  So the use of "In other words" is misleading.

  With regard to 4.1.1.7 apparently pseudonym user names do not include a realm, but fast re-authentication names do.  It would be helpful if this were mentioned in 4.1.1.7, with some indication of the reason for the difference. (If the reason is complex, just a mention of the difference would still help.)

  Shouldn't the literal 16384 in 4.1.7 (second paragraph) be a named notification code?  (There are multiple occurrences of this literal and 32768.)

  I presume that the last paragraph of 6.2 relates to existing EAP mechanisms, and that it is those mechanisms which mandate the response which needs to be ignored and the EAP-Success?  Presumably due to a lack of EAP knowledge, I could not parse this paragraph.

  Is the notation of section 9.1 for indicating attribute presence in messages (1, 0-1, 0*, 0) used in other EAP specifications?  It is understandable, but different from what I have seen used for other protocols.
2004-12-01
16 Harald Alvestrand
[Ballot comment]
Reviewed by Joel Halpern, Gen-ART. Review (with nits) in document comments.

His concern:

  The whole AKA-Notification mechanism, if I have understood it, …
[Ballot comment]
Reviewed by Joel Halpern, Gen-ART. Review (with nits) in document comments.

His concern:

  The whole AKA-Notification mechanism, if I have understood it, seems to be based on a concern that something is wrong with EAPs underlying notification / success / failure mechanism.  Just blithely re-implementing an existing mechanism (apparently for reasons of localization support) seems something that should be treated a little more seriously than appears here.  Have the EAP folks looked at this question?
2004-12-01
16 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2004-11-30
16 Thomas Narten [Ballot Position Update] New position, Yes, has been recorded for Thomas Narten
2004-11-30
16 Thomas Narten Ballot has been issued by Thomas Narten
2004-11-30
16 Thomas Narten Created "Approve" ballot
2004-11-30
16 (System) Ballot writeup text was added
2004-11-30
16 (System) Last call text was added
2004-11-30
16 (System) Ballot approval text was added
2004-11-29
14 (System) New version available: draft-arkko-pppext-eap-aka-14.txt
2004-11-24
16 Thomas Narten Placed on agenda for telechat - 2004-12-02 by Thomas Narten
2004-11-24
16 Thomas Narten State Changes to IESG Evaluation from AD Evaluation by Thomas Narten
2004-11-24
16 Thomas Narten
[Note]: '2004-11-23: Ready for full IESG review (when -14 appears). Note:
needed by 3GPP; document has been reviewed by EAP WG for conformance
with EAP, …
[Note]: '2004-11-23: Ready for full IESG review (when -14 appears). Note:
needed by 3GPP; document has been reviewed by EAP WG for conformance
with EAP, but security properties have not (and will not) be
reviewed. Document has been submitted a independent submission to RFC
Editor, but 3GPP (via liaison discussions) has requested that the
document be reviewed by IETF for conformance with EAP.
' added by Thomas Narten
2004-11-24
16 Thomas Narten
[Note]: '2004-11-23: Ready for full IESG review. Note: needed by 3GPP; document
has been reviewed by EAP WG for conformance with EAP, but security
properties …
[Note]: '2004-11-23: Ready for full IESG review. Note: needed by 3GPP; document
has been reviewed by EAP WG for conformance with EAP, but security
properties have not (and will not) be reviewed. Document has been
submitted a independent submission to RFC Editor, but 3GPP (via
liaison discussions) has requested that the document be reviewed by
IETF for conformance with EAP.' added by Thomas Narten
2004-11-24
16 Thomas Narten State Change Notice email list have been change to henry.haverinen@nokia.com, jari.Arkko@ericsson.com, stephen.hayes@ericsson.com from henry.haverinen@nokia.com, henry.haverinen@nokia.com, stephen.hayes@ericsson.com
2004-10-28
13 (System) New version available: draft-arkko-pppext-eap-aka-13.txt
2004-09-01
16 Thomas Narten
[Note]: '2004-09-01: Needed by 3GPP; will be reviewed by EAP WG for conformance
with EAP, but security properties will not be reviewed. Document has
been …
[Note]: '2004-09-01: Needed by 3GPP; will be reviewed by EAP WG for conformance
with EAP, but security properties will not be reviewed. Document has
been submitted a independent submission to RFC Editor, but 3GPP (via
liaison discussions) has requested that the document be reviewed by
IETF, hence I''m shepherding.
' added by Thomas Narten
2004-09-01
16 Thomas Narten Area acronymn has been changed to int from gen
2004-09-01
16 Thomas Narten Intended Status has been changed to Informational from None
2004-09-01
16 Thomas Narten Draft Added by Thomas Narten in state AD Evaluation
2004-09-01
16 Thomas Narten
[Note]: '2004-09-01: Needed by 3GPP; will be reviewed by EAP WG for conformance with EAP, but security properties will not be reviewed.' added by Thomas …
[Note]: '2004-09-01: Needed by 3GPP; will be reviewed by EAP WG for conformance with EAP, but security properties will not be reviewed.' added by Thomas Narten
2004-04-09
12 (System) New version available: draft-arkko-pppext-eap-aka-12.txt
2003-10-28
11 (System) New version available: draft-arkko-pppext-eap-aka-11.txt
2003-06-30
10 (System) New version available: draft-arkko-pppext-eap-aka-10.txt
2003-03-03
09 (System) New version available: draft-arkko-pppext-eap-aka-09.txt
2003-01-17
08 (System) New version available: draft-arkko-pppext-eap-aka-08.txt
2002-12-20
07 (System) New version available: draft-arkko-pppext-eap-aka-07.txt
2002-12-11
(System) Posted related IPR disclosure: Nokia's's Patent statement pertaining to draft-haverinen-pppext-eap-sim-07.txt and draft-arkko-pppext-eap-aka-06.txt
2002-11-07
06 (System) New version available: draft-arkko-pppext-eap-aka-06.txt
2002-10-03
05 (System) New version available: draft-arkko-pppext-eap-aka-05.txt
2002-07-01
04 (System) New version available: draft-arkko-pppext-eap-aka-04.txt
2002-02-28
03 (System) New version available: draft-arkko-pppext-eap-aka-03.txt
2001-11-21
01 (System) New version available: draft-arkko-pppext-eap-aka-01.txt
2001-05-17
00 (System) New version available: draft-arkko-pppext-eap-aka-00.txt