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

RE: Fixing identity and cert-sending



Hmmm... no one replied to this message, probably because everyone agrees
with it, or everyone disagrees with it, or some combination of both ;-)

Since it appears that no one else is going to speak up, I will say that I
like this idea, although you did leave out the fact that the old identity
types need to be preserved in order to act as "policy matching hints", as we
discussed earlier.

> For ID types 3 and 4: the URL scheme must be http

Does this support directories? If the URL points to a searchable directory
that is accessed using a protocol other than HTTP, does the initiator still
send the URL in this format and let the responder figure it out? Or would we
need more id types (since the responder would have to signal willingness to
use those protocols)?

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC
> Sent: Friday, March 29, 2002 1:45 PM
> To: ipsec@lists.tislabs.com
> Subject: Fixing identity and cert-sending
>
>
> We have an opportunity in successor-to-IKE to fix two major
> problems that
> have plagued us in IKEv1: a misunderstanding about what is
> identity, and
> having to send certificates every time because you don't know if the
> other party already has your certificate.
>
> This proposal (which could work in either IKEv2 or JFK) covers both
> topics at once because it turns out that they are related. Suggestions
> are welcome.
>
> The discussion below is for the successor-to-IKE proposals. Ignore
> everything about today's cert, certrequest, and ID payloads; they will
> not be used.
>
> Messages 1 and 2 MAY include a TrustedRoot payload. The TrustedRoot
> payload includes a series of one or more PKIX keyIdentifiers of roots
> trusted by the sender. This payload is completely optional and is
> used only to inform the recipient of what capabilities the sender has.
>
> Messages 1 and 2 MUST include exactly one IDAccepted payload.
> The payload
> holds a series of one or more fields indicating the FullID
> types that the
> sender will accept. The receiver MUST NOT send any FullID
> payloads that
> are not listed in the sender's IDAccepted payload.
>
> Messages 3 and 4 MUST include exactly one FullID payload. The
> payload's
> format is an ID type followed by content. The ID types are:
>
> 1  PKIX cert -- A standalone PKIX cert.
> 2  Cert bundle -- A simple ASN.1 sequence of PKIX certs. A bundle can
>        have end-entity certs or cert chains. The first cert
> in the bundle
>        is the sender's preferred identity certificate, but beyond that
>        there is no meaning to the ordering.
> 3  Hash-and-URL of PKIX cert -- The first 20 octets are the SHA-1 of a
>       certificate; the rest is a URL that resolves to the
> cert. This is
>       described in more detail below.
> 4  URL to a PKIX cert bundle  -- This is described in more
> detail below.
> 5  PKIX keyIdentifier -- Identifies a self-signed certificate that the
>       receiver has already pre-loaded. Note that this is only
> useful when
>       using self-signed certs.
> 6  IDForSharedSecret -- This is only for use with shared
> secrets. It is an
>       ASCII string (all octets are 31 < x < 127) of any length.
>
> For ID types 3 and 4: the URL scheme must be http, although
> it can be on
> any port, and there might be requirements for how the named
> part looks.
> The URL might be to a persistent repository, or it might be to the
> initiating machine (such as in a remote access client). For
> type 3, the
> recipient might cache the cert with the hash as an index, or it can be
> retrieved from the URL.
>
> If a system that is using certs knows that it cannot resolve
> URLs (because it
> is not yet on the Internet), it should use 1 and 2 in its
> IDAccepted payload.
> If a system can resolve URLs, it should use include type 3
> and 4. All systems
> should be able to handle bundles because the other party
> might have multiple
> identities which have different certificates.
>
> There will be new error codes:
> - Could not get your cert through the URL
> - Could not get your cert bundle through the URL
> - Bundle was malformed
> - Could not find the cert that matches the keyIdentifier
> - Could not use your IDForSharedSecret
>
> The authentication data needs to specify what kind of authentication
> is being used (signed or HMACed).
>
> --Paul Hoffman, Director
> --VPN Consortium
>