Subject: [manet] Queries on SAODV fields - Public key and signature

From: "Alan Yap" <[email-masked]>
Date: Mon, 14 Feb 2005 15:55:56 +0800 (SGT)

Hi,

There are no specifications on the public key and the signature fields of
the RREQ, RREP, etc extension of SAODV. Is it encoded in ASN.1 and are
there any specific encoding to follow?

If not, then how does one determine the length of these variable fields?

TIA
Alan

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Manel Guerrero <[email-masked]>
Date: Mon, 14 Feb 2005 16:17:03 +0100

Hi Alan :)

you are right.

In '14.1. SAODV Signatures'
there is only this:

8<-----------

    The block 'Signature Method ... Padding' is included before the
    'Signature' field in all the extension messages, and before the
    'Signature of the new Lifetime and Originator IP address' field in
    the RREQ-DSE message.

    This is the list of possible values of the Signature Method field:

                 RESERVED        0
                 RSA             1
                 Elliptic Curve  2
                 Reserved        3-127
                 Implementation
                 dependent       128-255

    All the implementations MUST support the RSA option.

----------->8

Which is clearly not specific enough. ;)

Specifying all this should be, IMO, the main target for the next
SAODV draft version.

Now I'm thinking that we could use PKCS#1 (Version 2.1) for
'Signature Method' 1 (RSA) and PKCS#13 for 2 (EC)
(if it ever gets standarized ;) ). (So, yeah, it would use ASN.1
and the encoding would be the one specified in the respective PKCSs)
And if there is people that need other signature methods they could
also be added.

But I'm completely open to other suggestions. Maybe a more compact method
(so that the length of the signature and the length of the encoded public key
would be shorter) could be more desirable.

Maybe this is a good moment for you guys to tell me how do you thing this
should get specified.

Best regards,

	Manel

---

From: Manel Guerrero <[email-masked]>
Date: Mon, 14 Feb 2005 19:06:23 +0100

Hi Alan :)

Another possibility would be to use a Signature Method for RSA
that would have:

Public Key:
	modulus
	exponent

Signature:
	signature

Where modulus, exponent and signature
are encoded in the following way:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Length            |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                             Value                             |
     ...                                                         ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and Length indicates the number of 32 bit words that occupy both
fields (length + value).

Manel

---

From: l s <[email-masked]>
Date: Mon, 14 Feb 2005 23:35:38 +0000 (GMT)

Dear MANET researchers,

MANETs are often employed on the 802.11 MAC.  In this
case only RTS, CTS, DATA, and ACK frames are ever used
and much of the frame bits are redundant as they
relating to various infrastructure related modes.  In
the DATA frame in particular, there are three
addresses, the Transmit Address, Receive Address, and
a 3rd address.

Has the 3rd address been utilised in a MANET for any
reason?  (I can only imagine somehow for gateways or
tunneling.)

I'd be grateful to know about research in which it has
been used in MANETs.

Thank you in advance,
   Lee Speakman
   CCSR, UniS
   Guildford
   UK

___________________________________________________________ 
ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

---

From: "Alan" <[email-masked]>
Date: Tue, 15 Feb 2005 11:37:12 +0800

Hi Manel,

This method which you suggested will simplify things. We could save the 
trouble and additional processing of ASN.1 parsing as the fields in SAODV 
are essentially a single attribute to single value mapping. We don't need 
the structural support that is provided by ASN.1 (as of now)

Cheers
Alan

----- Original Message ----- 
From: Manel Guerrero
To: Alan Yap
Cc: [email-masked]
Sent: Tuesday, February 15, 2005 2:06 AM
Subject: Re: [manet] Queries on SAODV fields - Public key and signature

Hi Alan :)

Public Key:
modulus
exponent

Signature:
signature

     0                   1                   2                   3

Manel

---

From: Manel Guerrero <[email-masked]>
Date: Tue, 15 Feb 2005 12:48:28 +0100

Hi Alan :)

Yep. I also thing this format's gonna be better.
Let's put it in this way:

8<----------------------------------------

14.1.1. Signature Method #1

    Public Key is composed of:
                 - Modulus
                 - Exponent

    Signature is composed of:
                 - Signature

    Where modulus, exponent and signature are encoded in the following
    way:

     0                   1                   2                   3
    |            Length             |           Reserved            |

    Length       The length of the Value field, (not including the Length
                 and Reserved fields) in 32-bit units.
    Reserved     Sent as 0; ignored on reception.

---------------------------------------->8

The reserved field might be used in the future for flags.
My intuition tells me we're gonna need them. ;)

Regards,

	Manel

Alan wrote:
> trouble and additional processing of ASN.1 parsing as the fields in 
> SAODV are essentially a single attribute to single value mapping. We 
> don't need the structural support that is provided by ASN.1 (as of now)
> 
> Cheers
> Alan
>