Hi Paul,
What I said was:
"I think there has to be a top-down analysis of RFC 4301 and how this
scheme impacts it. Each part of RFC 4301 that cannot be supported
or can only be supported in a limited manner must be spelled out and
the impact of the lack, or limit, of support has to be presented in
this draft's Security Considerations so a reader/implementer knows
what he's getting into if he decides to implement this scheme."
That's really what's needed, an enumeration of the issues and impacts.
The gateway cannot learn the authenticated identity and therefore the
assumptions RFC 4301 is making about that identity (viz, that it be
authenticated) no longer apply. The client can't learn the authenticated
identity but it does know that the entity asserting the unauthenticated
identity is trusted in some capacity (it got the key after all) by the
server it just authenticated. I think the ramifications of all that has
to be stated in the Security Considerations and I'd expect it to not be
a perfunctory statement.
I don't expect this draft to solve the "lying NAS" problem. But it
should not say it's solved by EAP methods with a "yes" in the table in
section 4. Such a statement is not true. It should say something to the
effect that "some EAP methods have the capability to pass blobs of data
and at some time in the future there may be a use of this capability to
solve the 'lying NAS' problem but until that time the following
considerations must be taken into account by people who implement this
scheme: blah blah blah." What is the impact of a client having this
transitively authenticated, but not really authenticated, identity of
the NAS even if the NAS is not lying? Does this impact change if
there's a human behind the "client" (who just wants network access)
or if it's a device protecting some of its own resources? The draft
doesn't say.
Basically, the Security Consideration section doesn't take into
consideration the full impact on security that will be caused by
implementation of this protocol; it should.
regards,
Dan.
On Wed, May 26, 2010 3:39 pm, Paul Hoffman wrote:
> At 2:22 PM -0700 5/26/10, Dan Harkins wrote:
>> I would advise a DISCUSS on this draft until this has been worked
>> out.
>
> Can you say more about what you mean by "worked out"? More text in the
> Security Considerations? If so, at least an outline would be helpful. Or
> maybe you mean one or more changes to the protocol? If so, some specific
> suggestions would be helpful. Specifically, are you asking for this
> document to solve the lying NAS problem?
>
> --Paul Hoffman, Director
> --VPN Consortium
>
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf