Subject: [HOKEY] The HOKEY charter and the authority of RFC 5247

From: Tom Taylor <[email-masked]>
Date: Thu, 12 Mar 2009 22:28:06 -0400

OK, I got the RFC number right this time around -- had 5462 on my mind for other 
work. I am wondering why RFC 5247 has been chosen to be the authority, as 
oppposed to the Hokey document RFC 5169, but never mind.

Looking at the draft and comparing with RFC 5247, it occurs to me that Qin's 
proposals are actually a hybrid. From the point of view of the Candidate 
Authenticator, it looks like proactive key distribution. However, from the point 
of view of the peer, it definitely looks like EAP pre-authentication.

So if we're going to get picky over terminology, the question is: which point of 
view is definitive?

Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Fri, 13 Mar 2009 09:04:00 -0400

Just to follow up on this comment, a four month debate over nuances of 
architecture seems worthy of the ITU-T and perhaps 3GPP, but perhaps out of 
place in the IETF. We should be focussing on the protocol aspects. As I've 
suggested already, the interaction between the Peer and the SA+AAA seems to be 
the same for EAP preauthentication proprement dit and Qin's scheme, and should 
therefore be covered by the same work item. The interactions between the SA and 
AAA and between the CA and AAA are clearly different between the two schemes and 
therefore are reasonably addressed by different work items.

Tom Taylor wrote:
> OK, I got the RFC number right this time around -- had 5462 on my mind 
> for other work. I am wondering why RFC 5247 has been chosen to be the 
> authority, as oppposed to the Hokey document RFC 5169, but never mind.
> 
> Looking at the draft and comparing with RFC 5247, it occurs to me that 
> Qin's proposals are actually a hybrid. From the point of view of the 
> Candidate Authenticator, it looks like proactive key distribution. 
> However, from the point of view of the peer, it definitely looks like 
> EAP pre-authentication.
> 
> So if we're going to get picky over terminology, the question is: which 
> point of view is definitive?
> 
> Tom Taylor
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey
> 
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 16 Mar 2009 14:18:55 -0400

Tom,

With regard to the interaction between the peer and the SA+AAA in
peer-SA-AAA-CA model, I don't think it has to be the same as the
interaction in EAP pre-authentication for the following reason.  

EAP pre-authentication requires to fit Figure 1 of RFC 5247, by
requiring CA to be involved in EAP authentication with the peer before
the EAP keying material is transported from the authentication server
to the CA.  Peer-SA-AAA-CA model is not EAP pre-authentication since
it does not require the EAP run between the peer and CA prior to
transport the EAP keying material from the authentication server to
the CA (and that's why it does not fit Figure 1).  Since
peer-SA-AAA-CA model is not EAP pre-authentication, it does not have
to follow Figure 1 of RFC 5247.  In fact, no part of peer-SA-AAA-CA
signaling actually requires EAP or ERP at all.  Let me also point out
that SA is not needed in peer-SA-AAA-CA model if the peer is able to
directly interact with AAA anchor-point to get the EAP keying material
transported to CA.

To me the peer-SA-AAA-CA model is a mobile-assisted version of
proactive key distribution, and nothing more or less than that, and
you will have more freedom in designing the new model by departing
from EAP pre-authentication.

Regards,
Yoshihiro Ohba

On Fri, Mar 13, 2009 at 09:04:00AM -0400, Tom Taylor wrote:
> architecture seems worthy of the ITU-T and perhaps 3GPP, but perhaps out 
> of place in the IETF. We should be focussing on the protocol aspects. As 
> I've suggested already, the interaction between the Peer and the SA+AAA 
> seems to be the same for EAP preauthentication proprement dit and Qin's 
> scheme, and should therefore be covered by the same work item. The 
> interactions between the SA and AAA and between the CA and AAA are 
> clearly different between the two schemes and therefore are reasonably 
> addressed by different work items.
>
> Tom Taylor wrote:

---

From: Tom Taylor <[email-masked]>
Date: Mon, 16 Mar 2009 22:30:42 -0400

Thank you for your response. I have two thoughts, one following from the other.
I would be interested in your view.

a) The SA is always needed to mediate between the peer and AAA, I think, because
the peer won't speak RADIUS or DIAMETER (leaving aside  questions of lower layer
transport).

b) It follows that the peer can't really see beyond the SA to tell whether it is
involved in EAP preauthentication or proactive key distribution, unless AAA
tells it. And I'm not sure there is a reason for AAA to do so.

Yoshihiro Ohba wrote:
> peer-SA-AAA-CA model is not EAP pre-authenticatiodn, it does not have

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 17 Mar 2009 15:05:16 -0400

Tom,

> the peer won't speak RADIUS or DIAMETER (leaving aside  questions of lower layer

If we assume that the peer has already network access through SA,
there is essentially no need for SA to be involved in proactive key
distribution signaling.  The peer does not need to speak AAA protocol.
Instead, it could use any protocol P via any entity X that resides
anywhere in the serving domain and speaks AAA, something like:

Peer-X-AAA-CA.

Unlike authenticator, entity X does not have to reside in every access
network, and protocol P does not have to be EAP or its extension.  It
is also possible that that the AAA anchor point (the home AAA server
or a AAA proxy) can be co-located with entity X.

> tells it. And I'm not sure there is a reason for AAA to do so.

Again, if we assume that the peer has already network access through
SA, the peer can see entity X beyond the SA.  Since protocol P does
not have to be EAP (or its extension) and EAP pre-authentication
always use EAP (or its extension), it is easy to distinguish EAP
pre-authentication and proactive key distribution if P!=EAP (or its
extension).

Regards,
Yoshihiro Ohba

---

From: Tom Taylor <[email-masked]>
Date: Tue, 17 Mar 2009 16:45:25 -0400

Thank you very much for your further consideration. I guess the conclusion is
that if one made the peer-X-AAA interaction in the proactive key distribution
case the same as the peer-SA-CA-AAA interaction in the EAP preauthentication
case, it would be only as a result of a design choice rather than design necessity.

I am assuming that in the general case the Peer-X-AAA-CA case is really
Peer-X-AAA-AAA-CA, where the second instance of AAA carries out authentication
in the candidate realm. That is, in the general case the peer needs a second set
of credentials. Is this reasonable?

> pre-authentication and proactive key distribution if P!=EAP (or its
...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 Mar 2009 12:20:33 -0400

> case, it would be only as a result of a design choice rather than design necessity.

Right.

> of credentials. Is this reasonable?

A second set of credentials seems unnecessary if the second instance
of AAA is just forwarding the key sent received from the first
instance of AAA towards the CA.  This would also apply where X==SA.

Thanks,
Yoshihiro Ohba

---

From: Tom Taylor <[email-masked]>
Date: Wed, 18 Mar 2009 21:18:27 -0400

You know, it may be possible to define a separate protocol, but I don't think it
would be a rational action on the part of the IETF. And I don't think we've
really identified the means by which the peer would know which model it was
working with. So I think the Peer-sA-AAA-CA model has to be explored in the
problem statement at least to the point of identifying where the models diverge.

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 19 Mar 2009 11:19:32 -0400

> would be a rational action on the part of the IETF. And I don't think we've

It depends on what design requirements of the new model are.

> problem statement at least to the point of identifying where the models diverge.

I have been suggesting to have a separate PS doc for the new model
that is qualified as proactive key distribution by I and other folks.
The architecturual aspects I pointed out for the new model (by using
entity X and protocol P) is unique to the new model and not applicable
to EAP pre-authentication.  Therefore, describing these aspects in the
same document as EAP pre-authentication PS can make the document much
less focused, and I don't suggest it.

Thanks,
Yoshihiro Ohba

---

From: Tom Taylor <[email-masked]>
Date: Thu, 19 Mar 2009 13:31:08 -0400

There is no point in having a tight focus if the requirements are broader than
that. Not only should we explore Peer-SA-AAA-CA in the problem statement, but
Alper should also provide the variants he has promised. That way we can see how
everything relates and make sure each interface doesn't have to be redesigned in
umpteen different variations.

If you're worried about the title of the document, I've said before, replace
"pre" by "early" and we don't infringe on any copyright.

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 20 Mar 2009 05:56:19 +0200

Tom,

> Alper should also provide the variants he has promised.

I will, as soon as the WG agrees to work out a new scope and re-charter
accordingly, which can very well happen once people who are blocking the
current progress give up on doing that.

Alper