Subject: Auth Method

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 6 Mar 2003 11:29:38 +0300

Greeting,

IKEv2-05 specifies only 2 values for Auth Method field in
Authentication Payload: Digital Signature (1) and Shared Key
Message Integrity Code (2). How could receiver unambiguously
determine what digital signature algorithm was used: RSA, DSA or
something else? By examining Authentication Payload length? - not
very reliable method. Via the other entity's certificate? - but
Certificate Payload is optional, and the entity may have several
certificates of different type.

In message http://www.vpnc.org/ietf-ipsec/mail-archive/msg02440.html
Charlie Kaufman wrote:

        Unless someone objects, I'll add a specifier of the
        authentication data type, of which we currently have 3: RSA
signature,
        DSA signature, and shared key HMAC.

So, the original intention was to make Auth Type more specific than we
have now, indicating what particular digital signature algorithm was used.
I'm curious what was the rationale to change that intention.

Another issue - how each side can advertise auth methods she supports.
In the same message there was some discussion on this topic and
suggestion to use CertRequest Payload for that purpose. Unfortunately,
it hasn't been done. Why? Are there strong objections against it?

Regards,
Valery Smyslov.

---

From: jeff pickering <[email-masked]>
Date: Thu, 06 Mar 2003 07:04:48 -0500

The public key type is encoded in the key itself. So even if you use
signatures without certs, you still have the information.

Jeff

---

From: [email-masked]
Date: Sun, 9 Mar 2003 20:57:07 -0500

> I'm curious what was the rationale to change that intention.

I really need a better filing system for things I say I will do unless
someone objects. In this case, I remembered to add the type code, but
forgot that you wanted separate ones for RSA vs DSA. I've now added a third
code value for DSA.

> it hasn't been done. Why? Are there strong objections against it?

I'm not convinced this is useful. It is only useful when one side can use
more than one set of credentials to authenticate and can't figure out which
the other side would prefer based on the CERTREQ. If we were to support
such a capability, my preference would be to put it in a NOTIFY payload
that the other end would be free to ignore if it didn't want to support
this case.

I don't think there were strong objections last time around, but neither
did I hear a groundswell of support. As I noted then, this could easily be
added to the protocol later in a backward compatible way if we discovered
we needed it.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 12 Mar 2003 07:19:56 -0500

I guess my point was that you must have a public key in order to try to 
verify the signature.
If you know the public key type, there is no real reason to also know 
the private key type used
by the remote end to sign. If there sender signs with a different 
private key type than
the public key he/she sent you, the sig just wont verify.

Of course, to determine the type of public key you hold, you need to do 
some ASN1 decoding.
Getting this from the AUTH payload may be easier for some 
implementations, so adding an
RSA/DSA differentiator may be helpful.

Regards,
Jeff

Valery Smyslov wrote:

> I don't think so. Authentication payload contains the signature, not the
> key.
> And encoding of this signature in payload is not defined in the
> document (BTW, I think it needs to be fixed anyway).
> And if encoding follows the same rules as in IKEv1 (PKCS#1 for RSA
> and raw signature for DSS), receiving side has no reliable means
> to distinguish between them.
> 
> Regards,
> Valery Smyslov.
> 
>> Valery Smyslov wrote:
>> 
>>> Greeting,
>>> 
>>> have now, indicating what particular digital signature algorithm was
>> 
> used.
>