[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Confirm decision on identity handling.



Hi Gregory,

Thanks for summarizing and trying to bring this to a close. I still have
some trepidation about the proposed text. I think we need to question
our underlying assumptions and I think problems arise from considering
all auth scenarios to be equivalent, and attempting to squeeze them into
a framework together in which the fit isn't quite right - square and
round pegs, round holes.

What is the purpose of the ID payload, and how is it used? There are two
overarching cases: preshared keys, and public/private keys. In the case
of preshared keys, the ID payload serves as a signal from the initiator
to the responder as to which psk the initiator (and therefore the
responder) will use. Note that this is not the same as a policy
selector, but functions similarly: wrong id payload implies selection of
wrong psk, resulting in authentication failure. For non-interactive
interoperability (e.g. no special config on the initiator side), the IP
address is used. Other cases require explicit configuration of the
initiator (key id, fqdn) in order to work.

In the case of public keys, the ID payload *may* indicate which public
key to use (assuming these keys are used without certs), but this has
never been clearly specified. When certs are used, the ID payload *may*
indicate which cert to choose, but only if the cert is not included in
the exchange - otherwise, the ID payload is superfluous. And the
currently defined ID payloads _don't uniquely define a cert_. A given DN
or GN may appear in certs from multiple issuers. The only way to
uniquely identify a cert is with explicit issuer identifying information
(issuer name, verification key, serial number, etc), but these are not
currently supported. So the ID payload is only a reliable policy
selector with interactive pre-configuration of the initiator, in which
it is explicitly told which ID to send, when the cert accompanies the ID
in the exchange, and when the intiator is trusted to do the right thing.

And what is the point of this? It seems to make the policy lookup
slightly simpler, since you can get the ID payload from the packet
instead of parsing the cert. But this is only on the front end, because
you still have to parse the cert, and you have the added step of
verifying that the ID matches something in the cert (if you care about
security). What threat does the first approach mitigate better than the
second? If I'm attacking, I can put an acceptable ID payload in the
packet, and then you'll sill have to parse the cert to find out I lied -
this is *more* work whether under attack or not.

I think the bottom line is that some vendors have come up with
proprietary ways to use the ID payload in their responder-side
processing. These methods make assumptions about the implementation at
the other end, and so long as these assumptions are correct (i.e. it is
the vendors own implementation at the other end), this works fine - but
it is not interoperable, and I think it actually incurs some additional
DoS risk. I don't see the point in standardizing on non-interoperable
functionality. It seems like a contradiction in terms.

Scott

Gregory Lebovitz wrote:
> 
> ==Attempted summary of thread to date:
> - Paul proposed final text.
> 
> - Gregory thought it was a bit too loose for interop, and proposed text with
> same intent, just more explicit (or at least I tried to). This text made it
> clear that interoperability bar is satisfied when when ID payload is used
> with certs and no connection is made between the two. It allowed for other
> use cases, but these would be implementation specific, and (honestly) are
> not guaranteed to interoperate.
> 
> - Scott asserts that in order to guarantee interoperability, as a
> responder I will need to have the ability to ignore the ID payload and
> parse the cert instead for policy lookup, so why not simply treat the cert
> as the ID in this case, and not add superfluous ID payloads which someone
> may or may not ignore? Scott wants it as cut and dry as possible, for the
> sake of interop.
> 
> - Jim K. would like the option to be able to use ID payload for policy
> lookup, and cert contents for credentials.
> 
> - we need something for policy lookup when the cert is not included in the
> exchange, but are used. ID payload is a way to do this.
> 
> == In order to finalize something, I would like to re-assert my proposed
> text and ask for either replacement text or to ratify this text:
> 
> Goals of text:
> > - the base interoperable way is DO NOT CHECK ID matches cert. This is the
> only guaranteed interoperable way.
> > - implementations MUST be able to handle IDs that do not
> > match cert contents
> > - implementations MAY be configured to match.
> > - Matching will only interoperate if both sides support the
> > feature and have matching turned on. (ie, we may not get good interop
> here)
> >
> > Proposed Text:
> > The Identification Payload, denoted ID in this memo, allows peers to
> > assert an identify to one another. The receiver will
> > interpret the identity
> > payload as a unique identity string for policy lookup in its SPD.
> > Implementations MUST NOT mandate a check that the ID match
> > anything in the
> > certificate presented, and therefore MUST be able to accept
> > the case where
> > the identity presented does NOT match the certificate contents.
> >
> > To allow for more stringent local security policy,
> > implementations MAY offer
> > a configuration option to check that the idenity presented in
> > the identity
> > payload matches the equivalent identity type in the presented
> > certificate.
> > In such a case, interoperability will only be achieved by two
> > consenting
> > parties who both have such configuration options available on their
> > respective gateways and who both enable the option.
> 
>  Gregory.