Re: IKEV2: Issue #4 Revised Identity

[Eric Rescorla <ekr@rtfm.com>]

I don't see how we can reasonably move forward with the revised identity
proposal as is, for a number of reasons:

(1) There's no way to use caching without having HTTP access.
    This is quite undesirable since these two issues are
    actually unrelated and it's reasonable to believe that
    there will be a significant number of agents which don't
    have HTTP access but can cache. Even if one believes that
    all agents have HTTP access, the need to do an HTTP
    fetch adds significant additional latency.

    What you actually want is for peer A to say "I have the
    following cert cached for you. Either send me an OK
    or send me a new cert." But there's no way to do that
    with this proposal. 


(2) It's underspecified.

    (a) The actual contents and encodings of TrustedRoot and IDAccepted
    payloads are not specified.

    (b) The actual data that's at the target of the URL is left
    unclear. What's the MIME type? What is the actual ASN.1 type
    of the data?
	
    (b) New error codes are invented but not actually assigned.

    

(3) Removal of semantically meaningful IDs. There are a number of
    different ways in which it might be meaningful to name a
    peer (e.g. IP address, FQDN, etc.) This proposal reduces
    the names to whatever happens to appear in the certificate.
    Since certificates often have multiple name forms of 
    different types, or worse yet, everything compressed into
    the CN, this proposal is going to make it very hard
    for a verifier to figure out what the peer's identity is.


(4) It invents new mechanisms to do things that do things that
    are already done (confusingly) in IKEv1. The problem with
    IKEv1 certificate handling is largely that it's underspecified.
    Keeping essentially the same certificate handling in IKEv2
    but clarifying the semantics allows us to tighten IKEv1
    as well. This is a good thing since we are probably stuck with
    IKEv1 for a while.

-Ekr



-- 
[Eric Rescorla                                   ekr@rtfm.com]
                http://www.rtfm.com/