Skip to main content

Handover Key Management and Re-Authentication Problem Statement
draft-ietf-hokey-reauth-ps-09

Revision differences

Document history

Date Rev. By Action
2012-08-22
09 (System) post-migration administrative database adjustment to the Yes position for Jari Arkko
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2008-03-12
09 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2008-03-11
09 (System) IANA Action state changed to No IC from In Progress
2008-03-11
09 (System) IANA Action state changed to In Progress
2008-03-11
09 Amy Vezza IESG state changed to Approved-announcement sent
2008-03-11
09 Amy Vezza IESG has approved the document
2008-03-11
09 Amy Vezza Closed "Approve" ballot
2008-03-11
09 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2008-03-02
09 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2008-02-24
09 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko
2008-02-23
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-02-23
09 (System) New version available: draft-ietf-hokey-reauth-ps-09.txt
2008-02-21
09 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2008-02-21
09 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2008-02-20
09 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-02-20
09 Jari Arkko
[Ballot discuss]
This is a good document, and I was quite happy with it.
I will move into a Yes position as soon as the …
[Ballot discuss]
This is a good document, and I was quite happy with it.
I will move into a Yes position as soon as the following
is fixed:

>  Inter-technology handover and
>  inter-administrative-domain handover are outside the scope of this
>  protocol.
...
>  EAP lower-layer independence:  Any keying hierarchy and protocol
>    defined MUST be lower layer independent in order to provide
>    capabilities over heterogeneous technologies.

These two text excerpts appear to be in conflict. If your solution is
lower-layer independent, you CAN provide inter-technology handovers.

> AAA protocol compatibility and keying:  Any modifications to EAP and
> EAP keying MUST be compatible with RADIUS [I-D.ietf-radext-design]
> and Diameter [I-D.ietf-dime-app-design-guide].  Extensions to both
> RADIUS and Diameter to support these EAP modifications are
> acceptable.  The designs and protocols must be configurable to
> satisfy the AAA key management requirements specified in RFC 4962
> [RFC4962].

Its funny that modifications to EAP have to conform only to RADIUS
specs. This is an error, and you must require (backwards) compatibility
to RFC 3748 and eap-keying.

> Compatibility:  Compatibility and co-existence with compliant
> ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be
> provided.  Specifically, the protocol should be designed such that
> fall back to EAP authentication occurs if not all devices in the
> network support fast re-authentication.

This a MUST requirement. We cannot allow existing EAP clients to
fail to get to the network merely because your optimization
requires new support. Also, your "all devices" statement is a bit
too vague. I think this should apply on a per-mobile node basis,
because the failure of another mobile node to support hokey should
not affect anyone else.

> 6. Use Cases and Related Work

This section still needs revision according to Bernard Aboba's comments
that relate to exactly what EAP and methods require. Specifically,
I did not see a mention that EAP-AKA actually goes all the way down
to one roundtrip + L2 transfer of identity + EAP Success. Be that
as it may, I am not trying to argue that this method or something
else should be used. What counts is the average or typical method
roundtrip count; you usually cannot change your method or credentials.
This should made clearer in the last paragraph of Section 6.1 and
in Section 3.

Also, Sections 6.2 and 6.3 use the argument that those optimizations
work well only within the given domain. However, the same argument
presumably works for ERX as well when a local server is used.

As Hannes brought up, the role of EAP delays in the overall network
access delay budget needs to be brought up, in the name of truth
in advertising. There is plenty of work on this. Reducing EAP
delays is still important, but when you remove one roundtrip from
a two roundtrip exchange that sounds very different from removing
one roundtrip from a dozen or so overall. (By my count, an unoptimized
IPv6 attachment to 802.11 with L2 security and L3 mobility turned on
is around 26 messages.)

Finally, some discussion of the deployment issues that Bernard Aboba
brought up would be useful. What nodes may change and what the
implications are. Note that I am not requiring you to change your
architecture -- but we do need to document what the deployment
implications are, again in the name of truth in advertising.
2008-02-20
09 Jari Arkko
[Ballot comment]
> EAP-SIM [RFC4186] and EAP-AKA [RFC4187] supports fast

s/supports/support/

> round trips and to complete, causing delays in re-authentication …
[Ballot comment]
> EAP-SIM [RFC4186] and EAP-AKA [RFC4187] supports fast

s/supports/support/

> round trips and to complete, causing delays in re-authentication and

s/and//
2008-02-20
09 Jari Arkko
[Ballot discuss]
This is a good document, and I was quite happy with it.
I will move into a Yes position as soon as the …
[Ballot discuss]
This is a good document, and I was quite happy with it.
I will move into a Yes position as soon as the following
is fixed:

>  Inter-technology handover and
>  inter-administrative-domain handover are outside the scope of this
>  protocol.
...
>  EAP lower-layer independence:  Any keying hierarchy and protocol
>    defined MUST be lower layer independent in order to provide
>    capabilities over heterogeneous technologies.

These two text excerpts appear to be in conflict. If your solution is
lower-layer independent, you CAN provide inter-technology handovers.

> AAA protocol compatibility and keying:  Any modifications to EAP and
> EAP keying MUST be compatible with RADIUS [I-D.ietf-radext-design]
> and Diameter [I-D.ietf-dime-app-design-guide].  Extensions to both
> RADIUS and Diameter to support these EAP modifications are
> acceptable.  The designs and protocols must be configurable to
> satisfy the AAA key management requirements specified in RFC 4962
> [RFC4962].

Its funny that modifications to EAP have to conform only to RADIUS
specs. This is an error, and you must require (backwards) compatibility
to RFC 3748 and eap-keying.

> Compatibility:  Compatibility and co-existence with compliant
> ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be
> provided.  Specifically, the protocol should be designed such that
> fall back to EAP authentication occurs if not all devices in the
> network support fast re-authentication.

This a MUST requirement. We cannot allow existing EAP clients to
fail to get to the network merely because your optimization
requires new support. Also, your "all devices" statement is a bit
too vague. I think this should apply on a per-mobile node basis,
because the failure of another mobile node to support hokey should
not affect anyone else.

> 6. Use Cases and Related Work

This section should be revised according to Bernard Aboba's comments
that relate to exactly what EAP and methods require (e.g. identity
req/resp is actually optional, the roundtrips of EAP AKA, running
EAP-TLS locally, etc).

Also, Sections 6.2 and 6.3 use the argument that those optimizations
work well only within the given domain. However, as far as I can see
2008-02-20
09 Jari Arkko [Ballot comment]
> EAP-SIM [RFC4186] and EAP-AKA [RFC4187] supports fast

s/supports/support/
2008-02-20
09 Jari Arkko
[Ballot discuss]
This is a great document, and I was very happy with it. I will move into a Yes position as soon as the …
[Ballot discuss]
This is a great document, and I was very happy with it. I will move into a Yes position as soon as the following is fixed:

>  Inter-technology handover and
>  inter-administrative-domain handover are outside the scope of this
>  protocol.
...
>  EAP lower-layer independence:  Any keying hierarchy and protocol
>    defined MUST be lower layer independent in order to provide
>    capabilities over heterogeneous technologies.

These two text excerpts appear to be in conflict. If your solution is
lower-layer independent, you CAN provide inter-technology handovers.

> AAA protocol compatibility and keying:  Any modifications to EAP and
> EAP keying MUST be compatible with RADIUS [I-D.ietf-radext-design]
> and Diameter [I-D.ietf-dime-app-design-guide].  Extensions to both
> RADIUS and Diameter to support these EAP modifications are
> acceptable.  The designs and protocols must be configurable to
> satisfy the AAA key management requirements specified in RFC 4962
> [RFC4962].

Its funny that modifications to EAP have to conform only to RADIUS
specs. This is an error, and you must require (backwards) compatibility
to RFC 3748 and eap-keying.

> Compatibility:  Compatibility and co-existence with compliant
> ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be
> provided.  Specifically, the protocol should be designed such that
> fall back to EAP authentication occurs if not all devices in the
> network support fast re-authentication.

This a MUST requirement. We cannot allow existing EAP clients to
fail to get to the network merely because your optimization
requires new support. Also, your "all devices" statement is a bit
too vague. I think this should apply on a per-mobile node basis,
because the failure of another mobile node to support hokey should
not affect anyone else.
2008-02-20
09 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2008-02-20
09 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-02-19
09 Tim Polk State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Tim Polk
2008-02-11
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-02-10
08 (System) New version available: draft-ietf-hokey-reauth-ps-08.txt
2008-02-09
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Hannes Tschofenig.
2008-02-06
09 Russ Housley
[Ballot discuss]
There are significant Last Call comments from Bernard Aboba and
  significant SecDir Review comments from Hannes Tschofenig. Taken
  together, I'm convinced …
[Ballot discuss]
There are significant Last Call comments from Bernard Aboba and
  significant SecDir Review comments from Hannes Tschofenig. Taken
  together, I'm convinced that a revised Internet-Draft is needed.
2008-02-06
09 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2008-02-06
09 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2008-02-05
09 Tim Polk Telechat date was changed to 2008-02-21 from 2008-02-07 by Tim Polk
2008-01-30
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Hannes Tschofenig
2008-01-30
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Hannes Tschofenig
2008-01-29
09 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2008-01-29
09 Tim Polk Ballot has been issued by Tim Polk
2008-01-29
09 Tim Polk Created "Approve" ballot
2008-01-24
09 Amy Vezza Last call sent
2008-01-24
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-01-23
09 Tim Polk Placed on agenda for telechat - 2008-02-07 by Tim Polk
2008-01-23
09 Tim Polk Last Call was requested by Tim Polk
2008-01-23
09 Tim Polk State Changes to Last Call Requested from AD Evaluation by Tim Polk
2008-01-23
09 (System) Ballot writeup text was added
2008-01-23
09 (System) Last call text was added
2008-01-23
09 (System) Ballot approval text was added
2007-12-21
09 Tim Polk State Changes to AD Evaluation from Publication Requested by Tim Polk
2007-12-06
09 Tim Polk Document shepherd is Glen Zorn
2007-11-10
07 (System) New version available: draft-ietf-hokey-reauth-ps-07.txt
2007-11-06
06 (System) New version available: draft-ietf-hokey-reauth-ps-06.txt
2007-11-02
05 (System) New version available: draft-ietf-hokey-reauth-ps-05.txt
2007-09-30
04 (System) New version available: draft-ietf-hokey-reauth-ps-04.txt
2007-09-10
03 (System) New version available: draft-ietf-hokey-reauth-ps-03.txt
2007-09-10
09 Tim Polk Draft Added by Tim Polk in state Publication Requested
2007-07-30
02 (System) New version available: draft-ietf-hokey-reauth-ps-02.txt
2007-01-25
01 (System) New version available: draft-ietf-hokey-reauth-ps-01.txt
2007-01-17
00 (System) New version available: draft-ietf-hokey-reauth-ps-00.txt